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PREFACE 


MANUAL OBJECTIVES 


The goal of this manual is to provide information necessary to prepare 
a conventional I/O driver for RSX-11M and subsequently incorporate it 
into an operational user-tailored system. A "conventional" driver is 
best explained by example. Disks and unit record devices are 
considered conventional; the LPS-11, UDC-1l1l, and TMll are considered 
unconventional. Complexity of device servicing requirements sets the 
dividing line, which is not easily established in black-and-white 
terms. 


INTENDED AUDIENCE 


The manual assumes that you understand the device for which you are 
writing a driver, and that you are familiar with the PDP-1l processor, 
its peripheral devices, and the software supplied with an RSX-11M 
system. Although this manual is organized tutorially, the intended 
audience is assumed to be at a system programmer level of expertise; 
thus, the manual does not contain definitions of data processing terms 
and concepts familiar to senior-level professionals. 


STRUCTURE OF THIS DOCUMENT 


This document proceeds from chapter to chapter toward increasingly 
detailed levels of implementation. 


Chapter 1 is a general introduction to I/O drivers in the RSX-11M 
system. 


Chapter 2 is a functional description of the RSX-11M device-level I/C6 
system. It discusses both data structure and code requirements. 


Chapter 3 details how to incorporate a user-written driver into the 
system. 


Together, Chapters 1, 2, and 3 provide a complete description of the 
requirements that must be met in creating a system that contains a 
user-written driver. 


Chapter 4 provides programming-level details on I/O data structures 
and on drivers that service several controllers. 


Chapter 5 discusses all the I/O-related Executive services. 
Chapter 6 gives two examples of user-written drivers. 


Appendix A describes the address doubleword. 


vii 


Appendix B outlines special considerations for extended memory NPR 
device drivers. 


Appendix C lists system macros that supply symbolic offsets for system 
data structures. 


Appendix D is a guide for the user in developing an Ancillary Control 
Processor (ACP). 


ASSOCIATED DOCUMENTS 


Familiarity with the system implies an in-depth exposure to _ the 
following manuals: 


e RSX-11M System Generation and Installation Guide 


e RSX-11M/M-PLUS I/O Drivers Reference Manual 


e@ RSX-1IM/M-PLUS Executive Reference Manual 
e@ RSX-1LIM/M-PLUS Utilities Manual 


e IAS/RSX-11 I/O Operations Reference Manual 
As adjuncts to this manual, you are advised to study existing I/0 
drivers. The RL-11l disk driver is a good example of an NPR device and 
the TA-11 (cassette) is illustrative of a programmed I/O device. In 
addition, a perusal of Executive source code contained in the files 
IOSUB, SYSXT, DROIO, BFCTL, and DRDSP (stored in UFD [11,10] on the 
Executive source disk) is recommended. 


Other manuals closely allied to the purposes of this document are 
described briefly in the RSX-11M/RSX-11S Information Directory and 
Index. The Information Directory defines the intended readership of 
each manual in the RSX-11M/RSX-115 set and provides a brief synopsis 
of each manual's contents. 
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SUMMARY OF TECHNICAL CHANGES 


This revision of the RSX-11M Guide to Writing an I/0 Driver 
incorporates the following technical changes and additions: 


i. 


Tables have been added to aid the user in establishing 1/0 
function bit masks for disk drives, magtape drives, and unit 
record devices (see Tables 4-3, 4-4, and 4-5). 


Error logging offsets have been added to the SCB and _ UCB. 
See the descriptions of the SCB and the UCB in Chapter 4. 


Other additions have been made to various UCB offsets: 


e New symbolic name U.MUP has been added (redefinition of 
U.CLI; see Chapter 4). 


e Symbolic names for magtape density bit masks have been 
added to the description of U.CW3 (see Chapter 4). 


e The DV.MBC offset to U.CWl has been renamed to DV.EXT (see 
Chapter 4). 


Some Executive routines listed in Chapter 5 have been moved 
to new Executive modules. The following is a list of the 
affected modules and subroutines: 


Routine Old Module New Module 


SACHKB/SACHCK IOSUB EXESB 
SASUMR IOSUB MEMAP 
SDEUMR IOSUB MEMAP 
SDVMSG IOSUB EXESB 
SMPUBM IOSUB MEMAP 
SMPUB1 IOSUB MEMAP 
SRELOC IOSUB MEMAP 
SSTMAP IOSUB MEMAP 
SSTMP1 IOSUB MEMAP 


In addition, the inputs to SMPUB1 have been modified (see 
Chapter 5). 


Three additional routines have been documented in Chapter 5: 
SEXROP, SQRMVF, and SSWSTK,. 


An appendix intended to aid the user in writing an Ancillary 
Control Processor (ACP) has been added (see Appendix D). 
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CHAPTER 1 


INTRODUCTION TO I/C DRIVERS 


The software supplied by DIGITAL for an RSX-11M system includes I/0 
drivers for a number of standard I/O devices. An I/O driver is a part 
of the RSX-11M Executive that services one type of I/O device. A 
driver may handle one or several controllers, each with one or several 
device-units attached. 


1,1 RESIDENT AND LOADABLE DRIVERS 


A driver can be resident or loadable. A resident driver is a 
permanent part of the Executive, incorporated at system generation. A 
loadable driver, while also part of the Executive, can be added to or 
unloaded from a system almost at will by means of MCR or VMR commands. 
During the system generation dialog, you can specify that you want 
this facility. 


Making drivers loadable can result in less Executive code, and thus 
permits an increase in available dynamic storage region (pool) space 
or increased space for user tasks. You can unload from the system any 
driver that is not needed for a period of time. For example, assume 
your system has both a paper tape reader and a card reader. T£— only 
one of them is connected to the system at any one time, you could load 
the driver for the on-line device and unload the other driver, thus 
reducing the size of the Executive. 


A loadable user-written driver is easier to incorporate into a system 
and easier to debug than a resident one. You can incorporate a 
resident driver into a system only during system generation; the 
Executive must be rebuilt and the system bootstrapped each time it is 
incorporated after debugging. In contrast, you can incorporate a 
loadable driver into a system with a single MCR command. 
Incorporating and debugging user-written drivers are discussed in 
Chapter 3. 


INTRODUCTION TO I/O DRIVERS 


1.2 FUNCTION OF AN I/O DRIVER 


An I/O driver is an asynchronous process (not a task) that calls and 
is called by the Executive to service an external I/O device or 
devices. The role of an I/O driver in the RSX-11M I/O structure is 
specific and limited. A driver performs the following functions: 


e Receives and services interrupts from its I/O device(s) 


e Initiates I/O operations when requested to do so by the 
Executive 


e Cancels in-progress I/O operations 


e Performs other (device-specific) functions upon power failure 
and device time-out 


As an integral part of the Executive, a driver possesses its own 
context, allows or disallows interrupts, and synchronizes its access 
to shared data bases with that of other Executive processes. It may 
also synchronize with itself: A driver can handle several device 
controllers (each with several device-units) all operating in 
parallel. A user-written driver must adhere to RSX-11M programming 
conventions in order to ensure the integrity of the Executive. 
Section 2.5 and Chapter 4 discuss these conventions. 


CHAPTER 2 


THE RSX-11M I/O SYSTEM--PHILOSOPHY AND STRUCTURE 


2.1 I/0 PHILOSOPHY 


Memory constraints and compatibility requirements dominated the design 
philosophy and strategy used in creating RSX-11M. To meet its 
performance and space goals, the RSxX-1iM I/0 system attempts to 
centralize common functions, thus eliminating the inclusion of 
repetitive code in each and every driver in the system. To achieve 
this centralization, a substantial effort has been expended in 
designing the RSX-11M data structures, which are used to drive the 
centralized routines. The effect is to reduce substantially the size 
of individual I/O drivers. The table structures require space and 
must be considered with the total size of the I/O system. 
Nevertheless, the size reduction effected by centralizing functions, 
combined with table-driven design, enables RSX-11M to meet its 
intended memory and performance goals. 


2.2 STRUCTURE 
The following sections: 


1. Place an I/O driver in the context of the overall RSX-11M I/O 
system 


2. Establish the responsibilities of an I/O driver 


3. Functionally describe the driver's interface to the Executive 
subroutines and the I/O data structures 


2.2.1 I/O Hierarchy 


The RSX-11M I/O system is structured as a loose hierarchy. The term 
"loose" indicates that you can enter the hierarchy at any of its 
levels; this characteristic is contrasted to "tight" hierarchies that 
permit entry only from the top level. Tight hierarchies exist 
principally for security and protection, but consume equipment 
resources. Figure 2-1 shows the loose RSX-11M I/0 system hierarchy. 


THE RSX-11M 1/0 SYSTEM--PHILOSOPHY AND STRUCTURE 


2.2.1.1 FCS/RMS - At the top of the hierarchy are File Control 
Services (FCS) and Record Management Services. (RMS), which provide 
device-independent access to devices included in a given’ system 
configuration. The user task has two levels with which to interface 
with FCS or RMS: Get/Put and Read/Write. Get/Put facilitates the 
movement of data records, whereas Read/Write provides a more basic 
level of access affording more direct control over data movement 
between a task and peripheral devices. 


Non-privileged 


Privileged 


User 1/0 
request 


Device- 
independent 
Device- 

dependent 


aio 
directive 


aio 
directive 


User state 


System state 


alo 
directive 
service 


Executive 
1/0 subroutines 


Device interrupt 


VO 


driver 
ZK-210-81 


Figure 2-1 I/0 Control Flow 


The discussion of FCS and RMS is brief because their existence is 
completely transparent to the driver and rarely concerns the writer of 
a conventional driver. FCS or RMS accepts a user request, interprets 
it, and translates it into a series of low-level system directives 
known as QIOs. 


2.2.1.2 QIO - The QIO directive is the lowest level of task I/O. Any 
task can issue a QIO directive which ailows direct control over 
devices that are connected to a system and that have an I/O driver. 
The QIO directive forces all I/O requests from user tasks to go 
through the Executive. The Executive works to prevent tasks from 
destructively interfering with each other and with the Executive 
itself. 
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2.2.1.3 Executive I/0 Processing - The Executive processes I/o 
requests using the following: 


1. An Ancillary Control Processor (ACP) 

2. A collection of Executive components consisting of: 
a. QIO directive processing 
b. I/O-related subroutines 
ec. The I/O drivers 


An ACP is responsible for maintaining the structure and integrity of 
data stored on file-structured volumes. It maps virtual I/O functions 
to logical I/O functions, and makes volume-protection checks. The 
driver converts a logical block number into a physical address on a 
file-structured device. No direct connection normally exists between 
the ACP and a driver. 


An ACP is a privileged task, and requires a partition in which to 
execute. Drivers, on the other hand, are specialized system 
Processes, not tasks. 


The Executive provides QIO directive processing. It also provides a 
collection of subroutines that are used by drivers to obtain I/0 
requests, to facilitate interrupt handling, and to return directive 
status codes. Actual control of the device is performed by the 
driver. These subroutines are examined in detail in Chapter 5. 
Executive subroutine services and QIO directive processing are shown 
as distinct components but are, in fact, both part of the Executive. 
These subroutines centralize common driver functions, thus eliminating 
duplicate code sequences among drivers. 


2.2.2 Role of I/O Driver in RSX-11M 


Every I/O driver in the RSX-11M system has the following five entry 
points: 


e Device interrupt+ 
e I/0 initiator 
e Device time-out 
e Cancel I/0 
e Power failure 
The first entry point is entered by a hardware interrupt; the other 


four are entered by calls from the Executive. Functional details 
regarding these entry points follow. 


l. A device may trigger more than one distinct interrupt entry. For 
example, a full-—duplex device would have two. 
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2.2.2.1 Device Interrupt - Control passes to this entry point when a 
dewice previously initiated by the driver completes an I/O operation 
and causes an interrupt in the central processor. The connection 
between the device and the driver in this instance is direct; the 
Exgcutive is not involved. 


2.2.2.2 I/O Initiator - The Executive calls this entry point to 
inform the driver that work for it is waiting to be done. In effect, 
this is a wake-up signal for the driver. 


2.3.2.3 Device Time-out - When a driver initiates an I/O operation, 
it can establish a time-out count. If the function then fails to 
complete within the specified time interval, the Executive notes the 
time lapse and calls the driver at this entry point. 


2.2.2.4 Cancel I/O - A number of circumstances arise within the 
system that require a driver to terminate an in-progress I/0 
operation. When such a termination becomes necessary, a task so 
informs the Executive, which then relays the request to the driver by 
calling it at the cancel I/O entry point. 


2.2.2.5 Power Failure - The Executive calls the driver's power- 
failure entry point in three different circumstances: 


@ When power is restored after a failure 
e When the system is bootstrapped 


e When the driver is loaded (if it is a loadable, as opposed to 
a resident, driver) 


Power Restore - Two conditions can initiate a call to the driver when 
power is restored following a power failure. First, the Executive 
automatically calls the power-failure entry point when power is 
restored any time the controller is busy (that is, when I/0 is in 
progress). Second, a driver has the option to be called regardless of 
the existence of an outstanding I/O operation at the time the power is 
restored (See the description of the UC.PWF bit symbol in Section 
4.1.4.1). Frequently, a driver's response to a power failure or to an 
I/O failure is identical to that when its device times out; in such a 
case, the power~failure entry point may simply be a RETURN 
instruction, because the driver will recover eventually via the 
time-out entry point. 


Bootstrap - When the system is bootstrapped, a power-failure interrupt 
is simulated. This simulation gives drivers the opportunity to carry 
out any appropriate preoperational initialization. 


Load - The MCR LOA command calls a loadable driver at its 
power-failure entry point if the device is on line and UC.PWF is set 
{see Section 4.1.4.1). 
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2.2.2.6 Summary--Role of an I/O Driver - Functionally, a driver in 
RSX-11M is responsible for: 


e Servicing device interrupts 
e Initiating I/O operations 
e Cancelling in-progress I/O operations 


e Performing device-related functions when a time-out or power 
failure occurs 


A driver exists as an integral part of the Executive; it can call, 
and be called by, the Executive. The driver initiates device I/0 
operations directly and receives device interrupts directly. All 
other entry points are entered by means of Executive calls. A driver 
never receives a QIO request directly, and has no direct interaction 
with the ACP. 


2.3 DATA STRUCTURES 
An I/O driver interacts with the following data structures: 
e Device Control Blocks (DCBs) 
e Unit Control Blocks (UCBs) 
e Status Control Blocks (SCBs) 
e@e The I/0 packet 
e The I/O queue 
e The fork list 
e Device interrupt vector 


The first four of these data structures are especially important to 
the driver, because it is by means of these data structures that all 
I/O operations are effected. They also serve aS communication and 
coordination vehicles between the Executive and individual drivers. 


The I/O queue and the fork list are actually Executive data 
structures, but are discussed here to illustrate all facets of the 
interaction of an I/O driver with the Executive. The I/O queue is a 
list of I/O packets built by the QIO directive, principally from 
information in the caller's Directive Parameter Block (DPB). The fork 
list synchronizes access to shared Executive data structures. 


Entry to a driver following a device interrupt is accomplished through 
the appropriate hardware device interrupt vector. As will be seen, 
writers of resident drivers are responsible for properly initializing 
this vector. It is discussed in conjunction with the data structures 
associated with a driver. 
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2.3.1 The Device Control Block (DCB) 


At least one DCB exists for each type of device appearing in a system 
(device type should not be equated with device-unit). The function of 
the DCB is to describe the static characteristics (rather than 
execution-time information) of both the device controller and the 
units attached to the controller. All the DCBs in a system form a 
forward-linked list, with the last DCB having a link of zero. Most of 
the data in the DCB is established in the assembly source for the 
driver data structure. The DCB is used by the QIO directive 
Processing code in the Executive and not by the driver. 


2.3.2 The Unit Control Block (UCB) 


One UCB exists for each device-unit attached to a system. Much of the 
information in the UCB is static, though a few dynamic parameters 
exist.l For example, the redirect pointer, which reflects the results 
of the MCR RED command is updated dynamically. As with the DCB, most 
of the UCB is established in the assembly source; however, its 
contents are used and modified by both the Executive and the driver. 
Usually, either the Executive or the driver -- but not both —-- modify 
a datum. 


2.3.3 The Status Control Block (SCB) 


One SCB exists for each device controller in the system. This is true 
even if the controller handles more than one device-unit (like the 
RL11 Controller). Line multiplexers such as the DH11 and DJll are 
considered to have one controller for each line because all lines can 
transfer in parallel. Most of the information in the SCB is dynamic. 
Both the Executive and the driver use the SCB. 


2.3.3.1 Interrelation of the I/0 Control Blocks - This’ section 
discusses the interrelationship among the DCB, UCB, and SCB without 
entering into the detailed contents of the control blocks, which are 
discussed in Chapter 4. 


Figure 2-2 shows the data structure that would result for three LA36 
DECwriters interfaced by means of a DH11 multiplexer. The structure 
requires one DCB, three UCBs, and three SCBs, because the activity on 
all three units can proceed in parallel. 


Figure 2-3 depicts the internal data structure for an RK1l disk 
controller with three units attached. Note that only one SCB exists, 
because only one of the three units can be active at any given time. 


1. From the UCB, however, it is possible to access most of the other 
Structures in the I/O data base (see Figure 2-5). In this sense the 
UCB gives access to a large amount of dynamic data. 
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Figure 2-4 shows the data structure for two RKll disk controllers, 
each of which has two drives attached. Here there are two SCBs, 
because both of the disk controllers can operate in parallel. 


Taken together, Figures 2-2, 2-3, and 2-4 illustrate the strategy 
underlying the existence of three basic I/O control blocks. There 
need be only one DCB for each device type. There may be one or more 
SCBs, depending on the degree of parallelism that is desired or 
possible: one for each device-unit, or one for each controller 
servicing several device-units. The number of UCBs and SCBs, and 
their interrelationships, are uniquely determined by the hardware 
these data structures describe. 


This data structure provides considerable flexibility in configuring 
I/O devices, and, because of the information density in the structures 
themselves, substantially reduces the code requirements of the 
associated drivers. 


Z2K-211-81 


Figure 2-2 DH11 Terminal I/O Data Structure 
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Figure 2-3 RK1l Disk I/O Data Structure 
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Pigure 2-4 1/0 Data Structure for Two RK11 Disk Controllers 


2.3.4 The I/O Packet 


An I/O packet contains information extracted from the QIO DPB, as well 
as other information needed to initiate and terminate I/O requests. 
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2.3.5 The I/O Queue Is 


Each time a task makes an I/O request, the Executive performs a series 
of validity checks on the DPB parameters. If these checks prove 
successful, the Executive generates a data structure called an I/0 
packet. The Executive then inserts the packet into a device-specific, 
priority-ordered list of packets called the I/O queue. Each 1/0 
queve's listhead is located in the SCB to which the I/O requests 
apply. 


When a device driver needs work, it requests the Executive to dequeue 
the next I/0 packet and deliver it to the requesting driver. 
Normally, the driver does not directly manipulate the I/O queue. 


2.3.6 The Fork List 


The fork list is a mechanism by which RSX-11M splits off processes 
that require access to shared data bases, or that require more CPU 
time to process an interrupt than is compatible with fast, real-time 
response of the overall system. 


A process that calls $FORK requests the Executive to transform it into 
a "fork process" and place it on the fork list. What this means is 
that a call to S$FORK saves a "Snapshot" of the process (registers R4, 
R5, and the PC) ina fork block. This fork block is queued on the 
fork list in first-in-first-out (FIFO) order. 


When a fork process has worked its way to the front of the fork list, 
R4 and R5 are restored and execution restarts at the statement after 
CALL $FORK. The process is unaware that a pause of indeterminate 
length has occurred. 


A fork process exists in a status intermediate between an interrupting 
routine and an ordinary task requesting system resources. Routines in 
the system stack--requests for interrupt processing--are run first. 
They can be interrupted only by higher-priority requests. Routines in 
the fork list are run when the system stack is empty--that is, they 
are completely interruptable. Finally, other tasks are run only when 
both the system stack and the fork list are empty. 


Driver interrupts are processed at priority 7 and are thus 
noninterruptable. By system convention, no process should run in a 
noninterruptable mode for more than 100 microseconds. This convention 
ensures prompt attention to interrupting real-time events. 


In practice, drivers servicing interrupts drop from priority 7 to a 
lower priority (namely, that of the interrupting source) after issuing 
a few instructions. Another system convention states that processing 


1. An exception is the case in which a driver needs to examine an I/0 
packet before it is queued, or in place of having it queued. For the 
driver to accomplish this examination, you must set the bit UC.QUE in 
the control byte (U.CTL) of the UCB (described in Section 4.1.4). 


The most common reason for a driver to examine a packet before queuing 
is that the driver employs a special user buffer, other than the 
narmal buffer used 


MULMaG. VuULe 


in transfer request. Within the context of the 
requesting task, the driver must address-check and relocate such a 
special buffer. See Section 6.3 for an example of a driver that does 


this. 
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at this partially interruptable level should not exceed 500 
microseconds. Often, more time than this is required to process an 
interrupt. The fork list mechanism provides a secondary interrupt 
stack whose members are processed first-in-first-out whenever the 
system stack is empty. 


A process can also call $FORK to access a shared data base--a system 
table, for example. You must strictly control such access in order to 
avoid conflicts. Under RSX-11M, many drivers can run in parallel; a 
multicontroller driver can run in parallel with itself. In these 
circumstances access to common data bases must be controlled. 


Of the two available methods of controlling such access--interrupt 
lockout and priority queuing--RSX-11M uses priority queuing. The fork 
list is the queue of requests for such access. Fork processeS are 
granted FIFO access to common data bases. Once granted such access, a 
process is guaranteed control of the data base until it exits. 


2.3.7 The Device Interrupt Vector 


The device interrupt vector consists of two consecutive words giving 
the address of the interrupt-service routine and the priority at which 
it is to run (always set to PR7). The low four bits of the second 
word of the interrupt vector must contain the number of the controller 
that interrupts through the vector. This requirement enables a driver 
to service several controllers with few code changes (see Sections 4.2 
and 4.3 for an example and discussion of multicontroller driver 
coding). Generally, these bits are set to 0. 


2.4 EXECUTIVE SERVICES 


The Executive provides services related to I/O drivers that can be 
categorized as pre- and post-driver initiation. The preinitiation 
services are those performed by the Executive during its processing of 
a QIO directive; these services are not available as Executive calls. 


The goal of pre-driver initiation processing is to extract from the 
QI0 directive all 1/0 support functions not directly related to the 
actual issuance of a function request to a device. If the outcome of 
pre-driver initiation processing does not result in the queuing of an 
I/O packet to a driver, the driver is unaware that a QIO directive was 
issued. Many QIO directives do not result in the initiation of an I/0 
operation. 


The post initiation services are those available to the driver after 
it has been given control, either by the Executive or as the result of 
an interrupt. They are available as needed by means of Executive 
calls. 


An important concept used in this section and in Section 2.5 is the 
"state" of a process. In RSX-11M, a process can run in one of two 
states: user or system. Drivers operate almost entirely in the 
system state; the programming standards described in Section 2.5 
apply to system-state processes. 


2.4.1 
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Pre-Driver Initiation Processing 


In processing a QIO directive, the Executive module DRQIO performs the 
following pre-driver initiation services: 


1. 


2. 


Checks to verify whether the supplied logical unit number 
(LUN) is legal. If not, the directive is rejected. 


If the LUN is valid, checks to verify whether a valid UCB 
pointer exists in the Logical Unit Table (LUT) for the 
specified LUN. This test determines if the LUN is assigned. 
If the test fails, the directive is rejected. 


If steps 1 and 2 are successful, traces down the redirect 
chain to locate the correct UCB to which the I/O operation 
will actually be directed. 


Checks the event flag number (EFN) and the address of the I/0 
Status Block (IOSB). If either is illegal, the directive is 
rejected. Immediately following validation, the Executive 
resets the subject event flag and clears the IOSB. 


Obtains 18 words of dynamic’ storage and builds the 
device-independent portion of an I/O packet. 


If steps 1 through 5 succeed, the Executive sets the 
directive status to +l. 


Note that directive rejections in any of the above steps are 
completely transparent to the driver. Such rejections cause 
a return of carry bit set. 


Checks the validity of the function being requested and, if 
appropriate, checks the buffer address, byte count, and 
alignment requirements for the specified device. 


If any of these checks fails, the Executive calls the I/0 
Finish routine (S$IOFIN). SIOFIN sets the I/O status and 
clears the QIO request from the system. 


If the requested function does not require a call to the 
driver, the Executive takes the appropriate actions and calls 
SIOFIN. 


If all I/O packet checks are positive, the Executive places 
the I/0 packet in the driver queue according to the priority 
of the requesting task, or gives the packet to the driver (if 
bit UC.QUE is set--see Section 4.1.4.1). 


2.4.2 Post-Driver Initiation Services 


Once a driver is given control following an I/O interrupt or by the 


Executive 


driver. 


itself, a number of Executive services are available to the 
These services are discussed in detail in Chapter 5. 
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However, four Executive services merit special emphasis because 
virtually every driver in the system uses them: 


e Interrupt Save (SINTSV) 
e Get Packet (SGTPKT) 
e Create Fork Process (S$FORK) 


e I/0 Done ($IODON or SIOALT) 


2.4.2.1 Interrupt Save (SINTSV)1 - Interrupts from a device are 
“fielded by the driver. Immediately following the interrupt, the 
driver operates at hardware priority level 7 and is, therefore, 
noninterruptable. If the driver needs a lengthy processing cycle 
(greater than 100 microseconds) to process the interrupt, or if it 
requires the use of any general-purpose registers, it calls SINTSV. 
This call queues external interrupts, alters the hardware priority, 
and provides the calling routine with two free registers to use in 
processing the interrupt. SINTSV is discussed in more detail in 
Section 2.5. 


2.4.2.2 Get Packet (SGTPKT) - The Executive, after it has queued an 
I/O packet, calls the appropriate driver at its I/0-initiator, entry 
point. The driver then immediately calls the Executive routine $GTPKT 
to obtain work.2 If work is available, SGTPKT delivers to the driver 
the highest-priority, executable I/O packet in the driver's I/O queue, 
and sets the SCB status to "busy." If the driver's I/O queue is empty, 
SGTPKT returns a no-work indication. If the SCB related to the device 
is already busy, S$GTPKT so informs the driver, and the driver 
immediately returns control to the Executive. 


Note that, from the driver's point of view, no distinction exists 
between no-work and SCB busy, because an I/O operation cannot be 
initiated in either case. 


2.4.2.3 Create Fork Process ($FORK) - You can synchronize access to 
shared data bases by creating a fork process. When a driver needs to 
access a shared data base, it must do so as aé_ée fork process; the 
driver becomes a fork process by calling $FORK. The SCB contains 
preallocated storage for a 4- or S-word "fork block." See Section 
4.1.3.1 for a description of the fork block. Section 5.3 contains 
details on SFORK. 


1. A loadable driver on a mapped system cannot call SINTSV directly. 
See Section 4.3. 


2. An exception is a driver that handles special user buffers. Such a 


driver must call certain other Executive routines before calling 
SGTPKT. See Section 6.3 for an example. 
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An interrupt routine cannot call $FORK directly; the routine must 
first switch to system state by using the INTSV$ macro or calling 
SINTSV (as described in Section 2.4.2.1). Furthermore, the 
interrupting routine's priority is lowered to that of the requesting 
source, 


After calling $FORK, a routine is fully interruptable (priority 0), 
and its access to shared system data bases is strictly linear. 


2.4.2.4 I/O Done (S$IODON or S$IOALT) - At the completion of an I/O 
request, the subroutines SIODON or SIOALT perform a number of 
centralized checks and additional functions: 


e Store status if an IOSB address was specified 

e Set an event flag, if one was requested 

e Determine if a checkpoint request can now be honored 
e Determine if an AST should be queued 


$SIODON and S$IOALT also declare a significant event, reset the SCB and 
device unit status to "idle," and release the dynamic storage used by 
the completed I/O operation. 


2.5 PROGRAMMING STANDARDS 


RSX-11M I/O drivers function as integral components of the RSX-11M 
Executive. They must follow the same conventions and protocol as the 
Executive itself if they are to avoid complete disruption of system 
service. This manual has been written to enable you to incorporate 
I/O drivers into your system. Failing to observe the internal 
conventions and protocol can result in poor service and a reduction in 
system efficiency. 


2.5.1 Process-Like Characteristics of a Driver 


A driver is an asynchronous Executive process. As a process, it 
possesses its own context, allows or disallows interrupts, and 
synchronizes functions within itself (all drivers can be parallel, 
multiunit, multicontroller) and with other Executive processes 
executing in parallel. 


Most RSX-11M drivers are small. Their small size is made possible by 
a comprehensive complement of centralized services available by calls 
to the Executive, and by the availability of an information-dense, 
highly formalized I/O data structure. 


2.5.2 Programming Conventions 


Appendix E of the PDP-11 MACRO-11 Language Reference Manual describes 
Program coding standards. DIGITAL recommends that users refer to 
these standards to assist in preparing standards for their own 
installations. 
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2.5.3 Programming Protocol 


Because an I/O driver accepts interrupts directly from the devices it 
controls, the central Executive relies on the driver to follow strict 
programming protocol so that system performance is not degraded. 
Furthermore, the protocol ensures that the driver properly distributes 
shared resources according to user-specified priorities. The protocol 
is summarized in Section 2.5.3.4. 


When a device interrupts, an I/O driver is entered. The driver 
usually calls $INTSV or issues the INTSV$ macrol for common save and 
state-switching services. At the completion of the services provided 
by INTSVS or SINTSV, the interrupt routine is again given control to 
complete the interrupt service. The exit routine $INTXT restores’ the 
state prior to switching to the system state, controls the unnesting 
of interrupts, and makes checks on the state of the system (for 
example, it checks to determine whether it is necessary to switch 
stacks). The fork processor causes access to shared system data bases 
to be linear. The details of all these routines are given in Chapter 
5. 


The interrupt vectors for each controller type in low memory contain a 
program counter (PC) unique to each interrupting source and a 
Processor Status Word (PSW) set with a priority of 7. It is a system 
software convention to use the low-order four bits of the PSW to 
encode the controller number for multicontroller drivers. When a 
device interrupt occurs, the hardware pushes the current PSW and PC 
onto the current stack and loads the new PC and PSW (Set at priority 7 
with the controller number in the condition-code bits) from the 
appropriate interrupt vector. The driver then starts executing with 
interrupts locked out. A driver itself may be executing at one of 
three levels of interrupt sensitivity: 


l. At priority 7 with interrupts locked out. 


2. At the priority of the interrupting source; thus, interrupt 
levels greater than the priority of the interrupting source 
are permitted. 


3. At fork level, which is at priority 0. 


2.5.3.1 Processing at Priority 7 with Interrupts Locked Out - By 
internal convention, processing at this level is limited to 100 
microseconds. If processing can be completed in this time, either 
without using general-purpose registers or by saving and restoring the 
registers used, then the driver simply dismisses the interrupt by 
executing an RTI instruction. The interrupt is processed and 
dismissed with minimal overhead. 


2.5.3.2 Processing at the Priority of the Interrupting Source - If 
the driver requires additional processing time or requires the use of 
general-purpose registers, it calls the SINTSV routine. Loadable 
drivers on mapped systems must use the INTSV$ macro. All other 
drivers can use the INTSVS$ macro or call the SINTSV routine directly. 
The priority at which the caller is to run is included in the call to 
the SINTSV routine. The driver sets this priority level to that of 
the interrupting source. 


1. The system macro INTSVS simplifies the coding of standard 
interrupt-entry processing (see Section 4.3). 
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The SINTSV routine sets up the interrupt routine so that it can be 
interrupted by devices with priorities higher than that of the 
interrupting source, and switches to system state if the processor is 
not already in system state. 


The SINTSV routine also saves registers R4 and R5 to free these 
registers for the driver. (A standard practice is for the driver to 
set R4 to the address of the interrupting device's SCB, and R5 to its 
UCB address.) An internal programming convention assumes that the 
driver will not require more than these two registers during interrupt 
processing. If it does, the driver must save ‘and restore any 
additional registers it uses. Processing time following the return 
from the SINTSV routine should not exceed 500 microseconds.1 


NOTE 


In actual practice, every driver in the 
system calls the SINTSV routine on every 
interrupt, due to three factors: 


1. It is difficult to service an 
interrupt without using one or two 
registers. 


2. Most interrupt code can safely be 
executed at the priority of the 
interrupting source. Executing at 
that priority is more desirable in 
terms of system response than 
continuing to execute at the highest 
priority. 


3. The SINTSV routine is an integral 
part of the interrupt mechanism for 
loadable drivers. 


2.5.3.3 Processing at Fork Level - A driver calls S$FORK to become 
fully interruptable (so that it conforms to the 500-microsecond time 
limit), or to access the shared system data base. The INTSVS macro 
must be issued or the SINTSV routine must be called prior to calling 
SFORK. 


By calling $FORK, the routine becomes fully interruptable and its 
access to system data bases is strictly linear. At fork level, all 
registers are available to the process, and R4 and R5 retain the 
contents they had on entrance to $FORK. 


1. The 500-microsecond period is a guideline. The longer the period 
of time a real-time executive spends at an elevated priority level, 
the less responsive is the system to devices of equal or lower 
priority. This guideline is especially important if the device being 
serviced is at the same or higher priority than a character-interrupt 
device such as the DU11, which is vulnerable to data loss due to 


interrupt lockout. 
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2.5.3.4 Programming Protocol Summary - Drivers are required to adhere 
to the following internal conventions when processing device 
interrupts: 


1. No registers are available for use unless SINTSV has_ been 
called or the driver explicitly performs save and restore 
operations. If SINTSV is called, registers R4 and R5 are 
available; any other registers must be saved and restored. 


2. Noninterruptable processing must not exceed twenty 
instructions, and processing at the priority of the 
interrupting source must not exceed 500 microseconds. 


3. You must use a fork process for all modifications to system 
data bases. 


2.6 FLOW OF AN I/O REQUEST 


Following an I/O request through the system at the functional level 
(the level at which this chapter is directed) requires that limiting 
assumptions be made about the state of the system when a task issues a 
QIO directive. The following assumptions apply: 


e The system is up and ready to accept an I/O request. All 
required data structures for supporting devices attached to 
the system are intact. 


e The only I/O request in the system is the sample request 
under discussion. 


e The example progresses without encountering any errors that 
would prematurely terminate its data transfer; thus, no 
error paths are discussed. 

The I/O flow proceeds as follows: 

Le {Task issues QIO directive] 

All Executive directives are called by means of EMT 377. The 
EMT causes the processor to push the PSW and PC on the stack 
and to pass control to the Executive's directive processor. 


a. First-level validity checks 


The QIO directive processor validates the LUN and UCB 
pointer. 


b. Redirect algorithm 


Because the UCB may have been dynamically redirected 
by an MCR Redirect command, QIO directive processing 
traces the redirect linkage until the target UCB is 
found. 


c. Additional validity checks 
The EFN and the address of the I/0 status’ block 


(IOSB) are validated. The event flag is reset and 
the I/O status block is cleared. 


2. 
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[Executive obtains Storage for and creates an I/O packet] 


The QIO directive processor now acquires an 18-word block of 
dynamic storage for use as an I/O packet. It inserts into 
the packet data items that are used subsequently by both the 
Executive and the driver in fulfilling the I/O request. Most 
items originate in the requesting task's Directive Parameter 
Block (DPB). 


{Executive validates the function requested] 
The function is one of four possible types: 
@ Control 
e No-op 
e ACP 
e Transfer 


Control functions are queued to the driver. If the function 
is IO.KIL, the driver is called at its cancel I/O entry 
point. The IO.KIL request is then completed successfully. 


No-op functions do not result in data transfers. The 
Executive "performs" them without calling the driver. No-ops 
return a status of IS.SUC in the I/O status block. 


ACP functions may require Processing by the file system. 
More typically, the request is a read or write virtual 
function that is transformed into a read or write logical 
function without requiring file system intervention. When 
transformed into a read or write logical, the function 
becomes a transfer function (by definition). See Appendix D 
for more information on ACP functions. 


Transfer functions are address checked and queued to the 
Proper driver. Then the driver is called at its initiator 
entry point. 


{Driver processing] 
a. Request work 


To obtain work, the driver calls the S$GTPKT routine. 
SGTPKT either provides work, if it exists, or informs the 
driver that no work is available, or that the SCB is 
busy. If no work exists, the driver returns to its 
caller. If work is available, S$GTPKT sets the device 
controller and unit to "busy," dequeues an I/Q request 
packet, and returns to the driver. If the I/O request is 
IO.ATT or IO.DET, the request is Processed by the 
Executive without returning the packet to the driver, 
unless UC.QUE is set. 


If UC.QUE is set, the packet is passed to the driver 
after the I0.ATT or IO.DET processing is completed. If 
the request is to be processed by an ACP, the packet is 
queued to the ACP, In either case, $GTPKT will look for 
another request for the driver. 
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b. Issue I/0 


From the available data structures, the driver initiates 
the required I/O operation and returns to its caller. A 
subsequent interrupt may inform the driver that the 
initiated function is complete, assuming the device is 
interrupt driven. 


5. [Interrupt processing] 


When a previously issued I/O operation interrupts, the 
interrupt causes a direct entry into the driver, which 
processes the interrupt according to the programming protocol 
described in Section 2.5. According to the protocol, the 
driver may process the interrupt at priority 7, at the 
priority of the interrupting device, or at fork level. Tf 
the processing of the I/O request associated with the 
interrupt is still incomplete, the driver initiates further 
I/O on the device (step 4b). When the processing of an 1/0 
request is complete, the driver calls $IODON. 


6. [I/O Done processing] 


SIODON removes the “busy" status from the device unit and 
controller, queues an AST, if required, and determines if a 
checkpoint request pending for the issuing task can now be 
effected. The IOSB and event flag, if specified, are 
updated, and $IODON returns to the driver. The driver 
branches to its initiator entry point and looks for more work 
(step 4a). This procedure is followed until the driver finds 
the queue empty, whereupon the driver returns to its caller. 


Eventually, the processor is granted to another ready-to-run 
task that issues a QIO directive, starting the I/0 flow anew. 


2.7 DATA STRUCTURES AND THEIR INTERRELATIONSHIPS 
This section introduces all the individual control blocks, as well as 
their linkages and use within the system. The following data 
structures comprise the complete set for I/O processing: 

1. Task header 

2. Window Block (WB) 

3. File Control Block (FCB) 


4. SDEVHD word, the Device Control Block (DCB), and the Driver 
Dispatch Table (DDT) 


5. Unit Control Block (UCB) 

6. Status Control Block (SCB) 

7. Volume Control Block (VCB) 
Figure 2-5, which provides the structure for the following discussion, 
shows all the individual data structures and the important link fields 
within them. The numbers on the figure are keyed to the text to 


simplify the discussion and _ to guide the reader through the data 
structures. 
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1. The task header is constructed during the task-build 
process.1 (It is one of two independent entries in the I/0 
data structure, the other being SDEVHD.) The task header 
entry of interest, the Logical Unit Table (LUT), is allocated 
by the Task Builder and filled in at task installation. The 
number of LUT entries is established by the UNITS= keyword 
option; this number is an upper limit on the number of 
device units a task may have active simultaneously. Each LUT 
entry contains a pointer to an associated UCB, and a_ pointer 
to a Window Block if a file is accessed by that logical unit 
number (LUN). 
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Figure 2-5 I/O Data Structure 


2. A Window Block (WB) exists for each active access to files on 
a mounted volume. It contains the context for the virtual 
patch used for validating I/O requests and converting virtual 
functions to logical functions. For disks, the WB consists 
of pointers to contiguous areas on the device. 


3. An FCP is a data Structure specific to the Files-11 disk ACP 
(FLIACP). It is used to control access to the file. 


1. In mapped systems, a copy of the task header (located in the task's 
partition) is made in the Executive's dynamic storage region. The 
Executive then uses this copy. To access the current information in 
this copy, a task must be privileged and have mapping to the 
Executive. 
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4. SDEVHD is a word located in system common (SYSCM) and is’ the 
other independent entry in the I/O data structure. SDEVHD 
points to a singly linked, unidirectional list of Device 
Control Blocks (DCBs). Each device type in a system has at 
least one associated DCB. The DCB list is terminated by a 
zero in the link word. 


Linked to each DCB is a Driver Dispatch Table (DDT), which is 
part of the driver. The DDT contains the addresses of the 
driver's four entry points that the Executive can call. 


5. A key data structure is the Unit Control Block (UCB). All 
the UCBs associated with a DCB appear in conSecutive memory 
locations. During internal processing of an I/O request, 
most drivers set R5 to the address of the related UCB. It is 
by means of pointers in the UCB that other control blocks in 
the data structure are accessed. In particular, the UCB 
contains pointers to the DCB, SCB, VCB, and to the UCB to 
which it may have been redirected. If a Redirect command has 
not been issued for the device-unit, the UCB redirect pointer 
points to the UCB itself. When servicing a request for one 
of its UCBs, the driver is unaware of whether I/0 was issued 
directly to its own UCB or to a UCB that had been redirected 
to its UCB. 


6. One Status Control Block (SCB) exists for each controller in 
a system. A unique SCB must exist for each 
controller/device-unit capable of performing parallel I/0. 
The SCB contains the fork-block storage required when a 
driver calls $FORK to transfer itself to the fork-processing 
level. The I/O request queue listhead is also contained in 
the SCB. Generally, register R4 contains the address of the 
SCB during processing of an I/O request. 


7. One Volume Control Block (VCB) exists for each mounted volume 
in a system. The VCB maintains volume-dependent control 
information. 


For Filles-1l disks, the VCB contains pointers to the File 
Control Definition Block (FCB) and Window Block (WB), which 
control access to the volume's index file. (The index file 
is a file of file headers.) The WB for the index file serves 
the same function as the WB for a user file. (See the 
IAS/RSX-11 r/o Operations Reference Manual for more 
information on the index file.) All unique FCBs for a volume 
form a linked list emanating from the index file FCB. This 
linkage aids in keeping file access time short. Further, 
since the window that contains the mapping pointers is 
variable in length, the user can increase file access speed 
by adding more access pointers (greater speed requires more 
main memory) to whatever extent the application requires. 


2.7.1 Data Structures Summary 


As the writer of a conventional driver, you do not manipulate the 
entire I/O data structure. In fact, you are usually involved only 
with the I/O packet, the UCB, and the SCB. The entire structure has 
been presented to add depth to your understanding of the I/O system, 
to emphasize the relationships among individual control blocks, and to 
clarify further the role a given driver fulfills in the processing of 
an I/O request. 


CHAPTER 3 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


If you want to support an I/0 device for which DIGITAL has not 
supplied a driver, you can write your own driver. Although this 
manual has not yet presented explicit details for writing such a 
driver, you now have enough conceptual information to consider 
incorporating one of your own drivers into your system. As will be 
seen, many considerations for writing a driver are best presented in a 
discussion of incorporating one. 


NOTE 


An alternative approach to writing your 
own device driver may be the CINTS 
(Connect to Interrupt Vector) directive. 
Refer to the description of the CINTS 


directive in the RSX-11M/M-PLUS 
Executive Reference Manual. For 


examples of the use of CINTS, examine 
the task-level . support routines for 
K-series laboratory peripheral modules, 
as described in Chapter 22 of the 
RSX-11M/M-PLUS I/O Drivers Reference 
Manual. amen 


3.1 OVERVIEW OF INCORPORATING USER-WRITTEN DRIVERS 


How you incorporate a user-written driver into the system depends 
mainly on whether you make your driver loadable or resident. If your 
driver is loadable, its data base can be either loadable or resident. 
If your driver is resident, both its data base and its code are 
resident. Thus, because you build the Executive image during system 
generation, you must include all resident driver elements in the 
Executive image during system generation. If your driver is loadable 
and has a loadable data base, you can incorporate it at any time after 
you build the Executive under which the driver runs. 


3.1.1 System Generation Support for User-Written Drivers 


During system generation, you answer questions concerning the types 
and quantity of peripheral devices on your system. Based on your 
answers, SYSGEN creates a single source file SYSTB.MAC that 
constitutes the data base definitions for DIGITAL-supplied devices on 
the system. Also created are the object modules of driver code to 
support the devices. Assembling SYSTB.MAC creates one module, 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


SYSTB.OBJ, which becomes the system device tables for the Executive 
and the data base for the system drivers. This module is linked into 
and becomes a permanent part of the Executive. 


A privileged system task invoked with the MCR/VMR LOA command is 
responsible for loading into memory a driver that is not resident. 
The LOA function creates the necessary interrupt control blocks (ICB) 
for accessing a driver in a mapped system, and establishes the linkage 
between the data base structures in the system device tables and_ the 
driver code being loaded. Another privileged system task invoked with 
the MCR/VMR UNL command can remove a loadable driver from memory. 
(Although the UNL function removes a loadable driver, it does not 
remove a loadable data base.) 


SYSGEN asks questions concerning the necessary driver support features 
in the Executive, to allow you to add user-written drivers. 


During the Target Configuration section of SYSGEN Phase I, answer the 
following question with the highest vector your system will use with 
the addition of your user-written driver: 


14. Highest interrupt vector [O R:0-774 D:0]: 


SYSGEN uses the specified address or 400, whichever is greater, to 
allocate sufficient vector space in the Executive to avoid run-time 
destruction of the system stack and to avoid hardware trapping (which 
occurs when the SP goes below 400). 


If any user-written driver is to be built loadable, SYSGEN must be 
notified of this fact. Loadable drivers require extra Executive 
features to support them (for example, the MCR/VMR LOA and UNL 
commands). You can choose support for loadable drivers by answering 
the following question in the Executive Options section of SYSGEN 
Phase I: 


15. Loadable device drivers? [Y/N]: 


The answer to the following question determines whether SYSGEN allows 
you to include a user-written driver in the system: 


25. Do you intend to include a user-written driver? [Y/N]: 


If you answer Yes, the next two questions are also asked (see Section 
5.3 of this manual): 


26. Include routine SGTWRD? [Y/N]: 
27. Include routine S$PTWRD? [Y/N]: 


NOTE 


If an LPAl1 device (LA:) is included in 
your system, the SGTWRD routine is 
automatically included and Question 26 
is not asked. If an ADO1 A/D controller 
device or an AFCl1l A/D controller device 
(AF:) is included in your system, the 
SPTWRD routine is automatically included 
and Question 27 is not asked. The 
SGTWRD and $PTWRD routines are described 
in Chapter 5 of this manual. 


To incorporate a user-written driver into RSX-11M, you first create 
two modules, one in which you define the data base and the other in 
which you include the driver code itself. You then must link your 
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driver data base and driver code modules into the system device 
tables in the Executive. The linkage that your data base module must 
satisfy is the link of the Device Control Block (DCB) list. The 
linkage for the driver code connects the DCB for the device that your 
driver supports to the Driver Dispatch Table (DDT). Moreover, if your 
driver is loadable, you must supply in your driver code symbols and 
labels that the LOA command needs. 


If your driver is loadable and has a loadable data base, you build (1) 
a loadable image containing the driver code module followed by the 
driver data base module, and (2) a symbol definition file on which the 
LOA command depends to find critical data base and driver locations. 
You build the driver image with the symbol definition file of the 
Executive under which the driver runs. However, the driver image is 
separate from the Executive image. The LOA command is responsible for 
loading both your driver data base and driver code, for connecting the 
data base to the system device tables, and for connecting your driver 
code to the data base. 


If your driver is loadable but has a resident data base, you must 
perform SYSGEN and build the Executive under which the driver runs to 
link your driver data base module(s) into the system device tables. 
This operation makes your driver data base resident with the system 
device tables. You also build (1) a loadable image containing the 
driver code, and (2) a symbol definition file which the LOA command 
uses to locate the driver dispatch table. The LOA command is 
responsible for loading your driver code and for connecting your 
driver code to the data base that is resident with the system device 
tables. 


If your driver is resident, you must perform a system generation and 
build the Executive to link the driver data base into the system 
device tables and to include the driver code in the Executive image. 


Because the LOA command provides consistency and validity checks on a 
data base being loaded, DIGITAL recommends that you make your driver 
and its data base loadable. Furthermore, with a loadable driver and 
loadable data base, you can more easily modify your driver and its 
data base. You need not rebuild your Executive and privileged tasks. 
To change the driver code, you need only build a new driver image, 
unload the current version, and reload the new version. To change the 
driver data base, you must build a new driver image (which 
incorporates the data base module), rebootstrap your system, and load 
the new driver to load the modified data base. (You must bootstrap 
your system to change the data base because the UNL command does not 
unload a data base, and because the LOA command does not load a data 
base for a driver if one is currently loaded for that driver.) 


NOTE 


If you use VMR to load the data base 
into the system image, rebooting the 
system will always load the data base. 


Using a loadable driver with a loadable data base may make more work 
in the short term but saves work in the long term. During debugging, 
data base inconsistencies are likely to be caught by the LOAD command. 
Thus, you prevent many such errors from later creating system 
problems. The procedure to make your driver operational is more 
complex because both the driver (and its data base) must be loaded 
each time the system starts up. 
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A resident driver or a loadable driver with a resident data base is 
easier to incorporate into the system but more difficult to debug and 
to modify. The LOA command does not perform consistency and validity 
checks on ae resident data base. Thus, a debugging aid is not 
available. Moreover, to modify such drivers, you must rebuild the 
Executive, which generally implies rebuilding the privileged tasks. 


The capability to incorporate a user-written driver into your system 
is a supported feature of RSX-11M. Because a user-written driver is 
considered a system modification, DIGITAL may not support the system 
that results after you incorporate your driver. Being a part of the 
Executive, your driver can subtly corrupt it. Therefore, DIGITAL 
cannot guarantee support which entails debugging user-written drivers. 
Fixing a problem in a system is largely a matter of being able to 
reproduce the problem reliably. If a problem on your system can be 
shown to have no relation to your driver, and DIGITAL will reproduce 
the problem, SPR support can be provided. A good reason for using a 
loadable driver with a loadable data base is that you can more easily 
test an unmodified system by not loading your driver and its data 
base. You can then reproduce a suspected problem in an _ unmodified 
system and can submit an SPR that DIGITAL will answer. Therefore, 
attempting to re-create a suspected problem on your system without 


your driver and its data base saves both you and DIGITAL time in 
answering the SPR. 


3.1.2 Overview of User-Written Driver Code 


To create the source code to drive a device, you must do _ the 
following: 


l. Thoroughly read and understand this manual. 


2. Familiarize yourself in detail with the physical device and 
its operational characteristics. 


3. Determine the level of support required for the device. 
4. Create the data base source code for the device. 


5. Determine actions to be taken at the five driver entry 
points: 


e Initiator 
e Cancel I/0 
e Time-out 
@ Powerfail 


e Interrupt 
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Create the driver source code. This code will contain the 
following global symbols (where xx is the 2-character 
alphabetic device mnemonic): 


SxxTBL:: Address of the driver dispatch table (see 
Section 4.1.2.1) 

SxxINT:: Address of the driver interrupt entry point 

SxxINP:: Addresses of input and output interrupt 

SxxOUT:: entry points (for full-duplex devices) 


If a loadable driver's loadable data base is to include the 
interrupt vector(s) for the case when the driver is resident, 
the conditional assembly symbol LD$xx must be included in the 
source code for the loadable data base. In addition, the 
code in the data base which includes the interrupt vector(s) 
must be enclosed in a conditional assembly block and defined 
as an ASECT. 


Loadable drivers have an additional requirement. Either 
within the driver source code itself or in file RSXMC.MAC, 
the conditional assembly symbol LDSxx must be defined. The 
INTSVS macro (see Section 4.3) uses this symbol (and others 
in RSXMC.MAC) to determine whether the call to S$INTSV_ should 
be omitted from the driver. 


The symbols used to name interrupt entries are different for 
devices that employ error logging. See the RSX-11M/M-PLUS 
Error Logging Reference Manual for information on modifying 
device drivers for error logging. Note that the error logger 
must be modified to log errors for a device that uses a 
user-written driver. 


The DIGITAL-supplied terminal driver (TTDRV) is treated as a 
special case by the LOA command in terms of the naming of its 
interrupt entries. 


3.1.3 Overview of User-Written Driver Data Bases 


Of the data structures associated with an I/0 driver, four require 
assembly source code: 


The DCB 
The UCB(s) 
The SCB(s) 


The device interrupt vector (assembly source required for 
resident drivers only) 
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A single DCB can service multiple UCBs and SCBs. The existence of 
multiple UCBs and SCBs is determined by the actual device subsystem 
being supported by a given driver in your hardware configuration. 
Figures 2-2, 2-3, and 2-4 illustrate possible DCB, UCB, and SCB 
Structural relationships. 


Within the DCB, UCBs, and SCBs, only those fields that are static or 
that need initialization must be supplied in your assembly source. 
Tables 3-1, 3-2, and 3-3 list these required fields. See Chapter 4 
for detailed figures and descriptions of these and other data 
structures. 


Table 3-1 
Required DCB Fields 


D.LNK Link to next DCB. This field is zero if this is the 
last (or only) DCB. If you are incorporating more 
than one user-written driver at one time, then this 
field should point to another DCB in a DCB chain. 


D.UCB Address of the first word (U.DCB) of the first UCB 
associated with this DCB. 

D. NAM Two-character ASCII generic device name. 

D.UNIT Highest and lowest logical unit numbers controlled by 
this DCB. 

D.UCBL Length of the UCB (including prefix words, if any). 


If a given DCB has multiple UCBs, all UCBs must be of 
the same length. 


D.DSP Address of the driver dispatch table. The dispatch 
table is located within the driver code. This field 
contains a global reference to the label associated 
with this table. The field is zero if the driver is 
loadable. 


D.MSK I/O function masks. You must supply bit-by-bit 
mapping for these four I/O function masks. Note that 
the format of the mask words is split into two groups 
of four words. Functions 0-15. are covered by the 
first group, and functions 16.-31. by the second. 


D. PCB Address of driver Partition Control Block (PCB). 
This field is required only if loadable driver 
support is included in the system. It must be 
initialized to zero. 
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Table 3-2 
Required UCB Fields 


Description 


Backpointer to the associated DCB 


Redirect pointer-~-initially contains the address of 
this UCB 


Control bits that must be established by the driver 
writer with the UCB source 


Unit status byte 


Physical unit number serviced by this UCB 


Unit status byte extension 


Characteristics word 1; Standard description (see. 
Section 4.1.4.1) applies 


Driver~-dependent 


Driver-dependent 


Default buffer size 


Address of the SCB for this UCB 


TCB address of attached task 


Table 3-3 
Required SCB Fields 


Offset Description 


I/O queue listhead 


Priority of interrupting source 


Interrupt vector address divided by 4 


Initial timeout count 


Controller index (that is, controller number 
multiplied by 2) 


Controller status 
Address of control and status register 


Fork block 


S.MPR Mapping register block; needed only by UNIBUS NPR 
devices running on DP~11l processor that employs 


extended-addressing it) mode 


SuwaAeaLe 


a 
(22- 
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3.2 USER-WRITTEN LOADABLE DRIVERS 


In deciding whether the data base for your loadable driver should be 
resident or loadable, consider the following characteristics of 
loadable data bases: 


e When you load a driver, the MCR/VMR LOA command checks to see 
whether a data base is resident for the type of device whose 
driver is being loaded. If a data base is not resident, the 
LOA command reads the driver symbol definition file to find 
the start and end of the data base in the driver image. 
(Thus, if your driver data base is to be loadable, you must 
have defined its start and end in the data base source code.) 
Knowing the start and end, the LOA command reads the data base 
from the driver image. The LOA command places the data base 
in the system pool so that it resides in Executive address 
space, accordingly relocates pointers and links within the 
data base to be valid Executive addresses, and also connects 
DCB(s) in the data base to the system device tables. 
Moreover, ‘the LOA command performs many consistency and 
validity checks on the data base being loaded so as to prevent 
the system device tables from being corrupted by an incorrect 
data base. 


e A loadable data base is only loaded once; thereafter, it is 
resident until the system is bootstrapped again. The UNL 
command does not remove a data base from memory even though 
the data base was loaded with the LOA command. 


e The LOA command relocates certain known pointers within the 

control blocks.l If the data base requires relocation of 
additional address pointers beyond the standard ones, it 
cannot be loaded with the LOA command. It must be 
incorporated into the system as a resident data base during 
system generation. 


During debugging of a loadable driver (with loadable data base), you 
can correct errors in the coding of the driver itself by unloading, 
modifying, assembling, task-building, and reloading the driver. 
However, if the data base must be replaced, the system must be 
bootstrapped to remove it. You can then modify, assemble, and 
task-build the data base, and reload it along with the (corrected) 
driver. 


The subsections below describe the procedure for incorporating a 
user-written loadable driver. 


3.2.1 Creating the Loadable Data Base and Driver Modules 


The general procedure for incorporating a loadable driver with a 
loadable data base is as follows: 


1. Complete SYSGEN Phase I and answer the appropriate questions 
that include the necessary driver support features in the 
Executive. Edit the assembly prefix file RSXMC.MAC and 
define a conditional symbol LD$xx for each loadable driver. 
See Section 3.1.1 for a discussion of system generation 
support. 


1. The pointers are: (DCB) D.LNK, D.UCB; (UCB) U.DCB, U.RED, U.SCB. 
(SCB) S.LHD+2. Chapter 4 gives details on these and other fields in 
the data base. 


3. 
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Complete SYSGEN Phase II. During Phase II you must edit 
RSXBLD.CMD, the Executive build command file (see Section 
3.3), and add the following line: 


GBLDEF=SUSRTB: 0 


(The symbol SUSRTB in the file [11,10]SYSTB.MAC defines the 
link word to a user-written driver's resident DCB. Adding 
this line forces the link word to be zero.) If you do not add 
this line when you do not have a resident data base, the Task 
Builder generates an undefined symbol error when it builds 
the Executive. However, you can disregard that error because 
the Task Builder sets the contents of the link word to zero. 


After SYSGEN Phase II completes, you can manually build the 
driver. 


After completing these steps, you can assemble the driver and data 
base at any time. 


4. 


While both the loadable driver and its data base can be 
contained in the same source module, it is recommended that 
you create separate sources for your driver and its data base 
and place them in UFD [11,10]. If, however, you place both 
the data base and the driver in the same module, you must 
ensure that, when linked, the data base follows the driver 
code. You can do this by physically placing the data base 
code after the driver code or by using .PSECT names to force 
proper allocation. 


A useful convention is to name your data base source xxTAB 
and your driver source xxDRV, where xx is the 2-character 
(alphabetic) device mnemonic. 


You must place the DCB first in the assembly source code of 
the driver data base module. In a multiuser protection 
system, the DCB must be followed first by the associated 
UCB(s) and then by the SCB(s). All UCB(s) associated with a 
particular DCB must be contiguous. DIGITAL-supplied drivers 
use this ordering scheme; see the file [11,10]SYSTB.MAC, 
created by Phase I of SYSGEN, for examples. Since you are 
creating a loadable data base for a single driver, your 
source code will contain a single DCB with associated UCB(s) 
and SCB(s). 


The global label $xxDAT:: marks the start of your driver's 
data base (the DCB). The global. label $xxEND:: marks the 
end of the data base (that is, immediately following the 
final word of the data base). These labels are absolutely 
required. The letters xx represent the 2-character device 
mnemonic. 


To assemble your driver, set the default UIC to [11,2x] and run _ the 
assembler as follows (user input underlined): 


>SET /UIC=[11, 2x] f 
>MAC er 
MAC >xxDRV,xxDRV=LB: [1,1] EXEMC/ML, LB: [11, 10] RSXMC,xxDRV ED 


To assemble the data base, use the following input to MAC: 


MAC>xx TAB ,xxTAB=LB: [1, 1] EXEMC/ML, LB: [11,10] RSXMC1,xxTAB ff) 
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Next, you use the following command to add both the driver and its 
data base to the Executive object module library: 


LBR>LB: [1, 2x] RSX11M/RP=[11, 2x] xxDRV,xxTAB @& 


3.2.2 Task-Building a Loadable Driver 


In this section, two examples of task-~building a loadable driver with 
a loadable data base are presented: one for a mapped system and one 
for an unmapped system. 


3.2.2.1 Task-Building a Loadable Driver on a Mapped System -— The 
following seven requirements apply to task-building any loadable 
driver, whether user-written or DIGITAL-supplied. 


1. You must specify a task image file name and a_ symbol 
definition file name as TKB output. Both files must be 
Placed in the UFD corresponding to the system UIC that will 
be in effect when the command is issued. The file names must 
both be xxDRV, where xx is the device mnemonic. The Task 
Builder produces output files named xxDRV.TSK and xxDRV.STB. 
For example, the beginning of input to TKB to build a 
paper-tape reader driver for a mapped system might appear as 
follows (user input underlined): 


>TKB (ED) 
TKB>[1,54]PRDRV/~HD/-MM, , [1,54] PRDRV= RED 
T T T tT 
Task image. Switches: see Symbol 
items 2 & 3 definition. 
below. 


2. You must not have a task header. Use the switch /-HD, as in 
the example above. A driver is not really a task but an 
extension of the Executive, and as such needs no task header. 


3. You must use the /-MM switch, whether in fact the driver is 
destined for a mapped or an unmapped system. 


4. You must link to the system symbol definition file that 
contains definitions of Executive global symbols. Continuing 
the paper-tape reader driver example referred to above, 
further TKB input might look like this: 


TKB>LB: [1, 24]RSX11M/LB: PRDRV: PRTAB fe) 


TKB> [1,54] RSX11M.STB/SS feD 


The first line above specifies the library file (/LB) in 
which the input driver object module and the object file for 
the loadable data base can be found. The object module 
specification for the driver must always precede the 
specification for the data base in the TKB command line. 


You omit the data-base file specifier when task-building any 
DIGITAL-supplied driver or one of your own drivers if it has 
a resident data base. All DIGITAL-supplied drivers that are 
declared loadable at system generation use resident data 
bases. 


3-10 


3.2.2.2 
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The second line in item 4 above indicates that the symbol 
table file RSX11M.STB is to be searched selectively (/SS) for 
definitions of Executive global symbols. Note that the /SS 
switch must appear in this context. It cannot be omitted. 


You must link to the system library file that defines masks 
and offsets used in the Executive. Continuing the example: 


TKB>LB: [1,1]EXELIB/LB f&) 
TKB>/ GED 


The single slash begins the option phase of the Task Builder. 


The driver code will execute as a part of the Executive, and 
thus the driver will use the Executive stack. Therefore, you 
must direct the Task Builder not to allocate space for a 
stack within the driver, as follows: 


TKB>STACK=0 f€) 
You must specify a partition for the driver. The 
specification differs for mapped and unmapped systems. 
Continuing the mapped-system example: 

TKB >PAR=DRVPAR: 120000: 4000 fen 

TKB>// GD 

> 


On mapped systems, the starting address of the partition must 
be 120000 octal. That is, the loadable driver must be mapped 
to kernel APR 5. 


On unmapped systems, the second parameter must be the 
physical starting address of the partition. 


On either mapped or unmapped systems, the length of the 
Partition may not exceed 4K words (20000 octal bytes). 


The double slash terminates the Task Builder's input. 


Task-Building a Loadable Driver on an Unmapped System - In 


the example below, we build a magtape driver for an unmapped system. 
The only differences from the mapped-system example are the partition 


starting 


address and the UFD of some of the files ([1,50] and [1,20] 


instead of [1,54] and [1,24], respectively). 


>TKB GED) 
TKB>[1,50]MTDRV/-HD/-MM, , [1, 50] MTDRV= SED 
TKB>LB: [1, 20] RSX1IM/LB:MTDRV:MTTAB f&) 
TKB>[1,50]RSX11M.STB/SS f 
TKB>LB: [1, 1] EXELIB/LB (ep 

TKB>/ @&) 

ENTER OPTIONS: @ 

TKB>STACK=0O eT) 

TKB >PAR=DRVPAR: 34000: 4000 f&0 

TKB>// GD =a 


> 
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3.2.3 Loading a User-Written Loadable Driver 
Loading is done by using the privileged MCR command LOA. Its form is: 
LOA xx: [/PAR=partition] 


where xx is the 2-character device mnemonic. Specifying a partition 
is optional. If none is specified, the partition input to the Task 
Builder is used. 


The LOA command requires that the two files xxDRV.TSK and xxDRV.STB 
reside under the system UFD (that is, the UFD established by the SET 
/SYSUIC command). Typically, this UFD is [1,50] for unmapped systems 
and [1,54] for mapped systems. 


LOA searches first for a resident data base for the driver being 
loaded. If none is found, LOA looks for the following global symbols 
in the symbol definition file xxDRV.STB: 


SxxDAT:: Address of the start of the data base (the DCB) 
associated with the driver 


SxxEND:: Address+2 of the last word of the data base 
associated with the driver 


3.2.4 Creating the Loadable Driver and Resident Data Base Modules 

If you decide upon a resident data base, you create the data base 
object module during SYSGEN Phase I. You use the same procedure as 
that for a resident driver. 

To create the resident data base, follow the procedure described in 
Section 3.3 with the exception of initializing the device interrupt 
vector. Since there is only one resident data base module (USRTB, 
which contains all the resident data bases), you assemble the resident 
data bases for loadable drivers with the resident data bases for 
resident drivers. 

To assemble the loadable driver, use the following command to MAC: 


MAC>xxDRV,xxDRV=LB: [1, 1] EXEMC/ML, LB: [11, 10]RSXMC,xxDRV @€) 


3.2.5 Building a Loadable Driver and Its Resident Data Base 
You build all resident data bases into the Executive as described in 
Section 3.3. You build the loadable drivers after the Executive is 
built. When SYSGEN asks the following question during Phase II: 

5, Driver 2-character device mnemonic [S]: 


enter the characters xx, where xx is the driver name. 


After your system is built, you can load your driver as described in 
Section 3.2.3. 
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3.3 USER-WRITTEN RESIDENT DRIVERS 


This section describes specific details for user-written resident 
drivers. 


1. Create the assembly source file for the resident data base in 
UFD [11,10]. Use USRTB.MAC as the file specification. USRTB 
as the file name is not actually required. It is, however, a 
useful convention -- as reflected in the sample dialogue 
described below. 


2. There is no mandatory ordering of the different control 
blocks in the data base. for your resident driver. It is 
suggested that you follow the convention of placing the DCB 
first, followed by the UCB(s), followed by the SCB(s). 
However, it is required that all UCB(s) associated with a 
particular DCB must be contiguous. DIGITAL-supplied RSX-11M 
drivers use this ordering scheme; see the file [11,10] 
SYSTB.MAC, created by Phase I of SYSGEN, for examples. If 
you are incorporating multiple resident drivers into your 
system, you will have more than one instance of a DCB with 
UCB(s) and SCB(s). 


3. Initialize the device interrupt vector (refer to Section 
4.1.5 for a description of this process). 


4, Use the global label S$USRTB:: as the address of your first 
(or only) DCB. This is absolutely required. 


During Phase I, SYSGEN asks: 
25. Do you intend to include a user-written driver? [Y/N] 


If you answer Yes, then subsequent questions guide you through the 
Process of adding the driver to the generated system. Refer to 
Section 3.1.1 for a discussion of system generation support and the 
questions asked. Operations performed include assembling the driver 
and its data structure, and editing the RSX-11M task-build command 
file. 


The following sample dialogue illustrates the addition of a resident 
driver for a PK: device. All user responses are underlined. After 
SYSGEN assembles the DIGITAL-supplied drivers, it prints some 
instructions, then pauses to allow you to assemble your driver(s), as 
follows: 


7 Assemble user-written driver(s) 


>i 
; The following instructions apply to resident drivers and 
; loadable drivers with resident data bases. 
ce 
7 Por loadable drivers, you must ensure that a symbol definition 
; of the format: 
; LDSxx=0 
; (where xx is the device name) appears in the assembly prefix 
: File [11,10]RSXMC.MAC for each loadable driver xxDRV. 
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>? SYSGEN will now pause to allow you to assemble your drivers(s) 
>; and USRTB module. Using a driver name xxDRV (where xx is 
>? the device name; for example, DK), you can type commands 
>? in the following format to assemble the driver and USRTB 
>? modules. 

; 

: MAC 
>? MAC>xxDRV=LB: [1, 1] EXEMC/ML, SY: [11,10]RSXMC,xxDRV 
7 MAC>USRTB=LB: [1, 1] EXEMC/ML, SY: [11,10]RSXMC,USRTB 
>? MAC>*Z 
AT. -- PAUSING. TO CONTINUE TYPE "RES ...AT." 
> 
>MAC 


MAC>PKDRV=LB: [1,1]EXEMC/ML, SY: [11,10]RSXMC,PKDRV @ep 
MAC>USRTB=LB: [1, L]EXEMC/ML, SY: [11, 10] RSXMC, USRTB 7) 
MAC > GIRuZ) 

> 

>RES ...AT. GE) 


AT. ~- CONTINUING 
> 
After you exit from MACRO-11 and type the command to resume, SYSGEN 


finishes Phase I. 


When you start Phase II, SYSGEN asks a few questions, prints some 
instructions, and pauses for you to build the driver(s) as follows: 


7 
>; Build user-written driver (s) 
>} You must now edit the Executive build command file RSXBLD.CMD 
: to include your user-written driver and data base in your system. 
>i 
>? If you are including a resident data base, locate the line 
>; in which the module SYSTB is referenced and add :USRTB 
>; immediately after it, for example: 
>: LB: [1, 24]RSX11M/LB:SYSTB: USRTB:SYTAB: INITL, LB: [1, 1] EXELIB/LB/SS 
; If you are not including a resident data base, add the line 
>; GBLDEF=SUSRTB:0 
>; to the file instead. 
7 
> For each resident driver, add a line of the form: 
>; LB: (1, 24]RSX11M/LB:xxDRV 
; where other drivers are referenced (where xx is the device name, 
>? for example DK). 
? NOTE: For each loadable driver, do not add a corresponding 
7 line to the build command file 
>i 
>? SYSGEN will now pause to allow you to edit RSXBLD.CMD. 
; After you exit from the editor and resume, SYSGEN builds the 
>: Executive and drivers. 
AT. -- PAUSING. TO CONTINUE TYPE "RES ...AT." 


>EDI RSXBLD. CMD®E). 

[00028 LINES READ IN] 

[PAGE 1) 

*L SYSTBRED 

LB: [1, 24] RSX11M/LB:SYSTB:SYTAB: INITL, LB: [1, 1] EXELIB/LB/SS 
*C /SYSTB:/SYSTB: USRTB: /fED 
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LB: [1,24] RSX11M/LB:SYSTB: USRTB:SYTAB: INITL, LB: [1, 1]E XELIB/LB/SS 
*L DYDRV ED 

[*EOB*] 

*T RET 

*L DYDRV Gen 

LB: [1,24]RSX11M/LB: DYDRV 

*I GED) 

LB: [1,24]RSX11M/LB: PKDRV 


*EX GED 
[EXIT] 


>RES ...AT.ED 

AT. -- CONTINUING 

After you perform the indicated operations and type the command to 
continue with SYSGEN, the Executive is built and you are given a 
chance to build any loadable drivers as follows: 

>: Build Loadable drivers 

>* 4, Build all selected loadable drivers into DRVPAR? [Y/N]: Y 

>; You can now build your user-written driver (if it is a loadable 

>; driver). If you choose not to build it now, or it is not loadable 
>; strike carriage return in response to the next question. 

>; When all drivers are built, strike carriage return 

>* 5S. Driver 2-character device mnemonic [S]: 


When Phase II completes, your resident driver is incorporated in the 
Executive and is ready to run. 


3.4 DRIVER DEBUGGING 
Because the protection checks provided for user programs are not 
available to system modules, driver errors are more difficult to 
isolate than user~program errors. But conventional drivers, because 
they are modular and short, probably can be easily debugged. This 
debugging process requires that you understand the following topics, 
each of which is discussed in a separate subsection: 

e Debugging aids and tools 

e Fault isolation 

e Fault tracing 


e Rebuilding and reincorporating a driver 
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3.4.1 Debugging Aids 


Adding a user-written driver carries with it the risk of introducing 
obscure bugs into an RSX-11M system. Since the driver runs as part of 
the Executive, special debugging tools are both desirable and 
necessary. RSX-11M provides several such aids, which can be 
incorporated into your system during system generation: 


e Executive stack and register dump 

e xXDT 

e Panic dump 

e Crash Dump Analyzer (CDA) support routine. 


You need not select any of this software during system generation. 
If, however, you do require the facilities they offer, you can select 
from one to three of them for incorporation in your system (panic dump 
and the CDA support routine are mutually exclusive). The following 
subsections describe the features and use of each debugging aid. 


3.4.1.1 Executive Stack and Register Dump Routine - At system 
generation, you can indicate that you want a dump of the Executive 
stack and the registers when a crash occurs. If you choose this 
option, the system will perform as follows: 


1. A system error, or the XDT X command (described in the next 
section), or operator manipulation of the switch register 
following a CPU halt, will cause processing to resume at 
location 40(octal). 


2. Location 40(octal) contains a JMP instruction that causes the 
Executive to execute the code beginning at location $CRASH. 


3. S$CRASH invokes the routine that dumps the Executive stack and 
registers as shown below: 


SYSTEM CRASH AT LOCATION 047622 
REGISTERS 

RO=000340 R1=177753 R2=000353 R3=000000 
R4=000004 R5=046712 SP=000472 PS=000340 
SYSTEM STACK DUMP 

LOCATION CONTENTS 

000472 000004 

000474 000000 

000476 001514 

000500 000340 

000502 177753 

000504 000353 

000506 000000 


000510 000000 
000512 057750 
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000514 002504 
000516 030011 
000520 100340 
000522 000340 
000524 056446 
000526 000000 
000530 102144 
000532 000000 
000534 101376 
000536 101372 
000540 102022 
000542 170000 


Following this display, either the CDA support routine or panic dump 
is invoked, depending on which (if either) is present in the system. 
Otherwise, the system halts. 


3.4.1.2 XDT - The Executive Debugging Tool - An interactive debugging 
tool has been developed for RSX-11M to aid in debugging Executive 
modules, I/O drivers, and interrupt service routines. This debugging 
aid, called XDT, is a version of the RSX-11 Octal Debugging Tool 
(ODT). XDT does not contain the following features and commands 
available on ODT: 


No SM (Mask) register 

No $X - (Entry Flag) registers 
No $V - (SST vector) registers 
No $D - (I/O LUN) registers 

No SE - (SST data) régisters 


No $W - (Directive Status Word) $DSW word 


No E - (Effective Address Search) command 
No F - (Fill Memory) command 

No N- —- (Not word search) command 

No V —- (Restore SST vectors) command 

No W - (Memory word search) command 


In addition, the X (Exit) ODT command has been changed for XDT. The X 
command causes a jump to the crash-reporting routine. 


Except for the omitted features and the change in. the X command, XDT 


is command-compatible with RSX-11 ODT; consequently, the IAS/RSX-11 
ODT Reference Manual can be used as a guide to XDT operation. 


XDT may be included in a system during Phase I of SYSGEN. The 
following question is asked: 


*30. Executive Debugging Tool (XDT)? [Y/N]: 
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Tf you answer Yes, then XDT is automatically included in the generated 
system. When the resultant system is bootstrapped, XDT takes control 
and types on the console terminal: 


XDT: <system version> 
followed by the prompting symbol 
XDT> 


You can set breakpoints at this time, and then type the G command, 
passing control to the RSX-11M Executive initialization code. 
Whenever control reaches a breakpoint, a printout similar to that 
produced by RSX-11 ODT occurs. 


You can initiate a forced entry to XDT at any time from a privileged 
terminal by means of the MCR BRK (breakpoint) command. Thus, the 
normal procedure is to type G when the system is bootstrapped without 
setting any breakpoints. When it becomes necessary to use XDT, the 
MCR BRK command is executed, causing a forced breakpoint. XDT then 
prints on the console terminal: 


BE:xxxXxXXX 
followed by the prompting symbol 
XDT> 


You can then set breakpoints and/or issue other xXDT commands. 
Continue system operation by typing the P (proceed) command to XDT. 


Note that XDT runs entirely at priority level 7 and does not interfere 
with user-level RSX-11 ODT. In other words, user-level RSX-1l1 ODT can 
be in use with several tasks, while XDT is being used to debug 
Executive modules. 


All XDT command I/O goes to and from the console terminal, and the L 
(List Memory) command can list on either the console or the line 
printer. 


Using XDT to debug a loadable driver on a mapped system has_ special 
pitfalls. One problem that can arise is a T-bit error: 


TE:xxxXXXX 
XDT> 


This error results when control reaches a breakpoint that you have 
set, using XDT, in a loaded driver on a mapped system. The T-bit 
error, rather than the expected BE: error, occurs unless register 
APR5 is mapped to the driver at the time XDT sets the breakpoint. 


To avoid this T-bit error, assemble the driver with an embedded BPT 
instruction, or use either the ZAP utility or the MCR OPE command to 
set the breakpoint by replacing a word of code with the BPT 
instruction. When control reaches a breakpoint set in this manner, 
XDT prints: 


BE:xxxxxX 
XDT> 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


Recover as follows: Using XDT, replace the BPT instruction with the 
desired instruction. Decrement the PC by subtracting 2 from the 
contents of register R7. Then proceed by using the P or S commands. 


NOTE 


You should not set breakpoints in more 
than one module that maps into the 
Executive through APR 5 or APR 6. In 
particular, do not set breakpoints in 
more than one loadable driver at a time 
or XDT will overwrite words of main 
memory when it attempts to restore the 
contents of breakpoints. 


3.4.1.3 Panic Dump - The Panic Dump routine saves registers RO 
through R6 and then halts, awaiting dump limits to be entered. 


The procedure for entering dump limits depends on whether your 
processor has a console switch register. The subsections that follow 
describe the procedure in each instance. 


3.4.1.4 Using the Panic Dump Routine on Processors with Console 
Switch Registers - For processors with console switch registers, you 
can obtain dumps of selected blocks of memory by using the following 
procedure: 


1. Enter the low dump limit in the console switch register and 
press CONT. The processor will immediately halt again. 


2, Enter the high dump limit in the console switch register and 
press CONT. The dump will begin on the device whose CSR 
address is DSSBUG (usually 177514, which is the line 
printer). The actual value of DSSBUG is determined during 
system generation when answering the panic dump question. At 
the end of the dump, the processor will again halt, awaiting 
the input of another set of dump limits. 


If your system does not have the Executive routine stack and 
register dump, enter the dump limits 0-520(octal) when the 
Panic Dump routine first halts. This causes dump of the 
system stack and the general registers. The limit 520(octal) 
changes if the highest interrupt vector is above 400 (octal). 
The actual upper limit is always the value of the global 
symbol $STACK and can be obtained from the global symbol 
listing in the Executive memory allocation map. 


3.4.1.5 Using the Panic Dump Routine on Processors Without Console 
Switch Registers - A number of PDP-11 processors are being delivered 
without a console switch register; they are configured with the M9301 
Console Emulator and Bootstrap. This presents no problem for the 
normal operation of RSX-11M, because it does not require a switch 
register. However, the Panic Dump Routine usually reads its arguments 
from the switch register. In systems that have been generated for 
processors that have no switch register, the panic dump module has 
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been altered to read its arguments from location 0. The following 
instructions are designed to allow you to enter the proper information 
to the Panic Dump Routine on processors equipped with the M9301 
Console Emulator. 


1. When the Panic Dump Routine halts, the RUN light will go out. 
At this time press and release the BOOT switch. 


The Console Emulator should display: 


AXXXXX XXXXXX XXXXXX nnnnnn 
$ 


where nnnnnn is the address+2 of the HALT instruction. 
2. You should enter the following: 


SL_0 ED 

$D_ low-address 
SL_nnnnnn en 

$S Gen 


3. The processor should again halt. Press and release the BOOT 
switch. 


The Console Emulator should display: 


XXXXXX XXXXXX XXXXXX mmmmmm 
$ 


4. You should then enter: 


SL_ OE 

$D high-addressé@en 
$L_mmmmmmen 
sa 


At this time the dump should commence. When it is finished, the 
Processor will halt and wait for additional input. 


3.4.1.6 Sample Output from Panic Dump - A portion of the output from 
Panic Dump is shown below. Output is in 3-line groupings. In the 
left-hand column, two addresses are shown. The first address is the 
absolute address; the second address is the dump relative address. 
The first line in a 3-line group gives the octal word value; the 
second line gives the two octal byte values of the word; the third 
line contains the ASCII representation of the bytes. The ASCII 
representations in each word are reversed to improve readability. The 
first output grouping from Panic Dump shows, proceeding from left to 
right, the address/absolute address, PS, RO, R1, R2, R3, R4, R5, and 
the SP. 


000544 000000 046076 000066 000000 000000 000000 o00000 045316 
000000 000 000 114 076 000 066 000 000 000 000 000 000 000 000 112 316 
“e “@ > L 6 “@ “@ *“@ “@ “@ *@ *@ *@ “*@ N J 


000000 022646 000340 045770 000340 045770 000340 045770 000340 
000000 045 246 000 340 113 370 000 340 113 370 000 340 113 370 000 340 
& % “@ K “@ K “@ K “€@ 
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000020 045776 000340 011124 000340 045770 000340 050500 000340 
000020 113 376 000 340 022 124 000 340 113 370 000 340 121 100 000 340 
K “@ T “R “@ K “@ @ Q “@ 


000040 000167 000543 000001 000001 000000 000000 000000 000353 
000040 000 167 001 143 000 001 000 001 000 000 000 000 000 000 000 353 
-@ “A “A *@ *A *@ “@ *@ *@ *@ *@ “%@ ~@ 


000060 035444 000340 034034 000340 032776 000340 032402 000340 
000060 073 044 000 340 070 034 000 340 065 376 000 340 065 002 000 340 
$i “@ “\ 8 “@ 5 “@ “B 5 “@ 


3.4.1.7 Crash Dump Analyzer Support Routine - The Crash Dump Analyzer 
(CDA) support routine, when entered, prints the following message on a 
notification device specified at SYSGEN: 


CRASH - CONT WITH SCRATCH MEDIA ON device mnemonic 


You can then put the secondary crash dump device on line and depress 
the CONT switch on the operator's console. The Executive Crash Dump 
routine will dump memory to the crash dump device and halt the 
processor upon completion. 


The procedure for subsequently invoking the Crash Dump Analyzer, which 


reads and formats the memory dump, is fully documented in the RSX-11M 
Crash Dump Analyzer Reference Manual. 


3.4.2 Fault Isolation 
Four causes can be identified when the system faults: 


e A user-state task has faulted in such a way that it causes the 
system to fault. 


e The user-written driver has faulted in such a way that it 
causes the system to fault. 


e The RSX-11M system software itself has faulted. 

e The host hardware has faulted. 
When the system faults, you must immediately determine which of these 
four causes is responsible. This section presents some procedures 


that can help you isolate the source of the fault. Correcting the 
fault itself is your responsibility. 


3.4.2.1 Immediate Servicing - Faults manifest themselves in roughly 
four ways (they are listed here in order of increasing difficulty of 
isolation): 


l. If XDT is included, an unintended trap to XDT occurs. 


2. The system displays text indicating a crash has occurred and 
haits. 
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3. The system halts but displays nothing. 
4, The system is in an unintended loop. 


The immediate aim, regardless of the fault manifestation, is to get to 
a point where you can obtain pertinent fault isolation data. 


The following discusssions assume the existence of a system built with 
at least one of the debugging aids described in Section 3.4.1. (Note 
that the minimal system does not have space for these routines.) 


Case 1--The system has trapped to XDT: 


The trap may or may not be intended (for example, a previously set 
breakpoint). If it is not intended, type the X command, causing XDT 
to exit to location 40(octal), from which the Executive stack and 
register dump routine (if present), followed by either Panic Dump or 
the CDA support routine (if present), will be invoked. If, however, 
you have some idea of the source of the problem (for example, a recent 
coding change), then you can use XDT to examine pertinent data 
structures and code. 


Case 2--The system has displayed text indicating a crash has occurred: 


If the text consists of output from the Executive stack and register 
dump routine (refer to Section 3.4.1.1), all the basic information 
describing the state of the system has been displayed. If the text 
has been produced by the CDA support routine, follow the procedure for 
obtaining and formatting a memory dump as outlined in the RSX-11 Crash 
Dump Analyzer Reference Manual. 


Case 3--The system has halted but displays no information: 


Before taking any action, preserve the current PS and PC and the 
pertinent device registers (that is, examine and record the 
information these registers contain). The procedure depends on _ the 
particular PDP-11 processor. Consult the PDP-11 Processor Handbook 
for details. 


After preserving the PS and PC, invoke your resident debugging aid: 
enter 40(octal) in the switch register, press LOAD ADDR, and then 
press START. The contents of 40(octal) cause the successive 
invocation of: 


1. The Executive stack and register dump routine (if present) 
2. Either Panic Dump or CDA support routine (if present) 

Case 4--The system is in an unintended loop: 

Proceed as follows: 
1. Halt the processor. 


2. Record the PC, the PS, and any pertinent device registers, as 
in case 3 above. 


You may then want to step through a number of instructions in an 
attempt to locate the loop. For this attempt to be meaningful you 
must first disable the system clock. Proceed as follows: Examine the 
contents of word 777546 (if your system has a line-frequency clock) or 
word 772540 (if it has a programmable clock). Clear bit 6 in this 
word and redeposit the word. 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


NOTE 


The system will not run until you have 
reenabled the clock. 


After trying to locate the loop and reenabling the clock, transfer to 
location 40(octal), as in case 3. 


3.4.2.2 Pertinent Fault Isolation Data - Before you attempt to locate 
the fault, you should dump system common (SYSCM). SYSCM contains a 
number of critical pointers and listheads. Find the appropriate 
limits for the module SYSCM by examining the Executive memory 
allocation map. Enter these limits to the Panic Dump routine or 
specify them in the command line used to invoke the Crash Dump 
Analyzer. 
In addition, you should dump the dynamic storage region and the device 
tables. The dynamic storage region is the module INITL and any 
additional space gained from the SET /POOL command and the device 
tables are in SYSTB. 
At this point, you have the following data: 

e Processor Status Word (PSW) 

e Program counter (PC) 

e Stack 

e RO through R6 

e Pertinent device registers 

e Dynamic storage region (pool) 

e Device tables 


@® system common 


These data are the minimum required for effectively tracing the fault. 


3.4.3 Fault Tracing 


Three pointers in SYSCM are critical in fault tracing. These pointers 
are described below: 


SSTKDP - Stack Depth Indicator 
This data item indicates which stack was being used at the time 
of the crash. SSTKDP plays an important role in determining the 
origin of a fault. The following values apply: 


+1--User (task-state) stack 


0 or less--System stack 
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If the stack depth is +1, then the user has crashed the system. 
In a system with "brickwall" protection (for example, the mapped 


RSX-11M system), the nonprivileged user should not be able to 
crash the system. 


STKTCB - Pointer to the current Task Control Block (TCB) 
This is the TCB of the user-level task in control of the CPU. 
SHEADR - Pointer to the current task header. 


The SHEADR word points to the header of the task currently 
running. The task header provides additional data to help 
isolate a fault. Figures 3-1 and 3-2 show the layout of task 
headers for unmapped and mapped systems, respectively. 


The first word in the header is the user's stack pointer (SP) the 
last time it was saved. If the user branches wildly into the 
Executive, the Executive terminates the user task, but the system 
continues to function (possibly erroneously). Knowing the user's 
stack pointer provides one more link in the chain that may lead 
to the resolution of the fault. 


The header (as pointed to by SHEADR) also contains the last-saved 


register set, just before the header guard word (the last word in 
the header--pointed to by H.GARD). 


H.HDLN 


Figure 3-l Task Header on an Unmapped System 


ZK-215-81 
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H.NLUN | 
H.GARD 
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Figure 3-2 Task Header on a Mapped System 


3.4.3.1 Tracing Faults Using the Executive Stack and Register Dump - 
To trace a fault after a display of the Executive stack and register 
contents, first examine the system stack pointer. Usually an 
Executive failure is the result of an SST-type trap within the 
Executive. If an SST does occur within the Executive, then the origin 
of the call on the crash-reporting routine is in the SST service 
module. (The crash call is initiated by issuing an IOT at a stack 
depth of zero or less.) 


A call to crash also occurs in the Directive Dispatcher when an EMT is 
issued at a stack depth of zero or less, or a trap instruction is 
executed at a stack depth of less than zero. The stack structure in 
the case of an internal SST fault is shown in Figure 3-3. 
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Figure 3-3 Stack Structure: Internal SST Fault 


The fault codes are: 


0 ;ODD ADDRESS AND TRAPS TO 4 

2 :MEMORY PROTECT VIOLATION 

4 ;BREAK POINT OR TRACE TRAP 

6 ;IOT INSTRUCTION 

10 ; ILLEGAL OR RESERVED INSTRUCTION 
12 7;NON RSX EMT INSTRUCTION 

14 ;TRAP INSTRUCTION 

16 711/40 FLOATING POINT EXCEPTION 
20 7;SST ABORT-BAD STACK 

22 :AST ABORT-BAD STACK 

24 ;ABORT VIA DIRECTIVE 

26 ;TASK LOAD READ FAILURE 

30 ;TASK CHECKPOINT READ FAILURE 
32 ;TASK EXIT WITH OUTSTANDING I/0 
34 ;TASK MEMORY PARITY ERROR 


The PC points to the instruction following the one that caused the SST 
failure. The number of bytes is the number normally transferred to 
the user stack when the particular type of SST occurs. If the number 
is 4, then a non-normal SST fault occurred, and only the PSW and PC 
are transferred. There are no SST parameters. 


If the failure is detected in $DRDSP, the stack is the same as_ that 
shown in Figure 3-3, except that the number of bytes, the 55T fault 
code (the fault codes are listed above), and the SST parameters are 
not present. The crash report message, however, will indicate that 
the failure occurred in $DRDSP. 
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One SST-type failure, stack underflow, does not result in the stack 
structure of Figure 3-3. To determine where the crash occurred, first 
establish the stack structure; this can be deduced by the value of 
the SP and the contents of the top word on the stack. If the stack 
structure is that of Figure 3-3, then the failure occurred in S$DRDSP, 
or was anormal SST crash. If the stack structure is that of Figure 
3-4, then an abnormal SST crash has occurred. 


<_—___-—___ 5p 


ZK-218-81 


Figure 3-4 Stack Structure: Abnormal SST Fault 


Abnormal SST failures occur when it is not possible to push 
information onto the stack without forcing another SST fault. When 
this situation occurs, a direct jump to the crash-reporting routine is 
made, rather than an I0T crash. The PS and PC on the stack are those 
of the actual crash, and the address printed out by the 
crash-reporting routine is the address of the fault rather than the 
address of the I0T that crashes the system. Note that the 
crash-reporting routine removes the PC and PSW of the IOT instruction 
from the stack, which in this case is incorrect. Thus, the SP appears 
to be four bytes greater than it really is (as in Figure 3-4). 


You now have all the information needed to isolate the cause of the 
failure. From this point on, rely on personal experience and a 
knowledge of the interaction between the driver and the services 
provided by the Executive. 


3.4.3.2 Tracing Faults When the Processor Halts Without Display - To 
trace a fault when the processor halts but displays no information 
(case 3 in Section 3.4.2.1 above), first examine $STKDP, $TKTCB, and 
SHEADR. The difficulty in tracing failures in this case is that the 
system stack is not directly associated with the cause of a failure. 


By examining SSTKDP, you can determine the system state at the time of 
failure. If it was in user state, the next step is to examine the 
user's stack. The examination focuses on scanning the stack for 
addresses that may be subroutine links that can ultimately lead to a 
thread of events isolating the fault. This is essentially the aim of 
looking at the system stack if $STKDP is zero or less. 


Frequently, a fault can occur that causes the SP to point to the top 
of the stack plus 4. This fault results from issuing an RTI 
instruction. The top two items on the stack are data. The result is 
a wild branch and then, most probably, a halt. Figure 3-5 shows a 
case in which two data items are on the stack when the program 
executes an RTI instruction. The top of the stack points to a word 
containing 40100(octal). If location 40100(octal) contains a HALT 
instruction, the original SP is four bytes below the final SP, and 
fault tracing should begin from the original SP. 
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Figure 3-5 Stack Structure: Data Items on Stack 


This type of fault also occurs when an RTS instruction is executed 
with an inconsistent stack. However, in that case, SP points to 
TOS+2. : 


A scan of the contents of the general registers may give some hint as 
to the neighborhood in which a fault (or the sequence of events 
leading up to the fault) occurred. 


If the fault occurred in a new driver, a frequent source of clues is 
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT), 
as are the activity flags (US.BSY and S.STS). Other locations in both 
the UCB and SCB may also provide information that may help locate the 
source of the fault. 


3.4.3.3 Tracing Faults After an Unintended Loop - To trace a fault 
when an unintended loop has occurred, first halt the processor. 


After you halt the processor, the same state exists as was discussed 
in Section 3.4.3.2. Follow the same tracing procedure described 
there. A specific suggestion is to check for a stack overflow loop. 
Patterns of data successively duplicated on the stack indicate a stack 
looping failure. 


3.4.3.4 Additional Hints for Tracing Faults - Another item to check 
is the current (or last) I/O packet, the address of which is found in 
S.PKT of the SCB. The packet function (I.FCN) defines the last 
activity performed on the unit. 


If trouble occurred in terminating an I/O request, a scan of the 
system dynamic memory region may provide some insight. This region 
starts at the address contained in SCRAVL, a cell in SYSCM. Because 
all I/O packets are built in system dynamic memory, their memory is 
returned to the dynamic memory region when they are successfully 
terminated. Following the link pointers in this region may reveal 
whether I/O completion proceeded to that point. In systems with QIO 
optimization, $PKAVL (SYSCM) points to a list of I/O packet-sized 
blocks of dynamic memory that are not linked into the $CRAVL chain. 


A frequent error for an interrupt-driven device is to terminate an I/0 
Packet twice when the device is not properly disabled on I/0 
completion and an unexpected interrupt occurs. This action ultimately 
produces a double deallocation of the same packet of dynamic memory. 
Double deallocation of a dynamic buffer in RSX-11M causes a loop in 
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the module SDEACB on the next deallocation (of a block of higher 
address) after the second deallocation of the same block. At that 
time, R2 and R3 both contain the address of the I/O packet memory that 
has been doubly deallocated. If XDT has been included in the system, 
the deallocation routine checks for bad deallocation and crashes the 
system if it occurs. 


3.4.4 Rebuilding and Reincorporating a Driver 


The procedure for rebuilding and reincorporating a driver into your 
system depends on whether the driver is resident or loadable. The two 
subsections that follow describe the Procedure for each kind ‘of 
driver. 


3.4.4.1 Rebuilding and Reincorporating a Resident Driver - The 
procedure for rebuilding and reincorporating a resident driver 
involves four steps: 


NOTE 
In the examples that follow: 


e x (as in [11,2x] is equal to 0 
for unmapped systems and 4 for 
mapped systems 


e xxDRV is the name of the driver 
you are rebuilding or 
reincorporating 


l. Correct and assemble the driver and/or device data 
structures. 


Assuming that the object system has been bootstrapped, 
appropriate volumes have been mounted, and the source code 
for the user driver and/or device data base has been updated, 
then the following commands effect the reassembly of both the 
driver and the data base: 


>SET /UIC=[11, 2x]@@. 
>RUN SMACRED 


MAC>xxDRV=LB:; [1, 1] EXEMC/ML, SY: [11, 10] RSXMC,xxDRV 


MAC >USRTB=LB: [1, 1] EXEMC/ML, SY: [11, 10] RSXMC , USRTBEED 
MAC >GRLZ) 


2. Update the Executive object module library. 


After reassembling the user driver and/or data base, you must 
update the Executive object module library. The following 
commands will accomplish this: 


>SET /UIC=[1, 2x] GE 


>RUN_SLBR fet 


LBR>LB: RSX11M/RP=[11, 2X] xxDRV, USRTBRED 


LB R>@RLZ) 
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3. Do Phase II of SYSGEN to rebuild the driver with the 
Executive. 


4, Bootstrap the new system. 


The new system can now be bootstrapped with the MCR BOO 
command. If you are using the baseline system, first issue 
the following command: 


>INS BOO ;-16E) 
Then issue the following command: 


>BOO [1,5x]RSX11M Ff 


3.4.4.2 Rebuilding and Reincorporating a Loadable Driver - A loadable 
driver is easier to reincorporate during debugging than a resident 
driver. After correcting and assembling the driver source, simply 
unload the old version, using the MCR UNL command, task-build the new 
one, and load it using the LOA command. 


The data structure, once loaded, becomes a permanent part of the 
Executive. It is not removed by the UNL command. If the data 
structure is in error and cannot be patched, correct its source, 
reassemble, and task-build it. Then bootstrap the system before 
loading the corrected driver. 


CHAPTER 4 
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In Chapter 2, overviews were given for: 

e Data structures 

e Executive services 

@® Programming protocol 
This chapter gives details for the data structures, and in addition 
discusses specifics of multicontroller drivers and the INTSVS macro. 
Executive services are covered in Chapter 5. The protocol coverage in 


the discussion of programming protocol in Chapter 2 is detailed enough 
to make further elaboration unnecessary. 


4.1 DATA STRUCTURES 


The following elements in the I/O data structure are of concern to the 
programmer writing a driver: 


e I/0 packet 


e DCB 
e UCB 
e SCB 


e Device interrupt vector 


The I/O data structure, and the first four control blocks listed above 
in particular, contain an abundance of data pertaining to input/output 
operations. Drivers themselves are involved with only a subset of the 
data. 


In the detailed descriptions of the I/O packet, the DCB, the UCB, and 
the SCB that follow, most data fields (words or bytes) are classified 
by one of five descriptions. Two items in each description indicate: 


e Whether the field is initialized in the data structure source 


e What sort of access the driver has to the field during 
execution 
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The five descriptions are: 


<initialized, not referenced> 
Field is supplied in the data structure source code, and is 
not referenced by the driver during execution. 


<initialized, read-only> 
Field is supplied in the data structure source code, and may 
be read by the driver. 


<not initialized, read-only> 
Either an agent other than the driver establishes this field, 
or the driver sets it up once and thereafter references it 
read-only. 


<not initialized, read-write> 
Either the driver or some other agent establishes this field, 
and the driver may read it or write over it. 


<not initialized, not referenced> 
Field does not involve the driver in any way. 


These five descriptions cover most of the fields in the four control 
blocks described in this section. Exceptions are noted in the text. 


The final discussion in this section deals with the device interrupt 
vector. 


4.1.1 The I/O Packet 


Figure 4-1 shows the layout of the 18-word I/O packet, which is 
constructed and placed in the driver I/0 queue by QIO directive 
processing, and is subsequently delivered to the driver by a call to 
SGTPKT. The DPB from which the I/O packet is generated is illustrated 
in Figure 4-2 (see Section 4.1.1.2). 


4.1.1.1 I/O Packet Details - The I/O packet is built dynamically by 
QIO directive processing. Thus, no static fields exist with respect 
to a driver. I/O packets are created dynamically, and therefore the 
first two descriptions in Section 4.1 (<initialized, not referenced> 
and <initialized, read-only>) do not apply. Fields in the I/O packet 
(described below) are classified as not referenced, read-only, or 
read-write. 


I. LNK 
Driver access: 
Not referenced. 
Description: 


Links I/O packets queued for a driver. A zero ends’ the 
chain. The listhead is in the SCB (S.LHD). 
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I. EFN 
Driver access: 
Not referenced. 
Description: 


Contains the event flag number as copied by OQI0O directive 
processing from the requester's DPB. 


LLUNK re) 
L.PRI 

LEFN q 
1LTCB TCB address of requester 4 


° 
° 


IL.PRM 24 


Device 
parameters 
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Figure 4-1 I/0 Packet Format 


I. PRI 


Driver access: 


Description: 


Priority copied from the TCB of the requesting task. 
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I.TCB 
Driver access: 
Read-only. 
Description: 
TCB address of the requesting task. 
I.LN2 
Driver access: 
Not referenced. 
Description: 
Contains the address of the second word of the LUT entry in 
the task header to which the I/O request is directed. For 
open files on file-structured devices, this word contains the 
address of the window block; otherwise, it is zero. 
I.UCB 
Driver access: 
Read-only. 
Description: 
Contains the address of the unit to which I/0 is to be 
directed. I.UCB is the address of the Redirect UCB if the 
starting UCB has been subject to an MCR RED command. Used in 
cancel I/O routine to determine if the I/O request is from 
the task that is issuing the SIOKIL routine. 
I. FCN 
Driver access: 
Read-only. 
Description: 
Contains the function code (see Table 4-1, Section 4.1.2.2) 
for the I/0 request. The modifier byte is one or more 
subfunction bits that may be set. 
I. IOSB 
Driver access: 
Not referenced. 


Description: 


I.IOSB contains the virtual address of the I/O Status Block 
(IOSB), if one is specified, or zero if one is not specified. 


I.IOSB+2 and I.IOSB+4 contain the address doubleword for the 
IOSB (See Appendix A for a detailed description of the 
address doubleword). On an unmapped system, the first word 
is zero; the second word is the real address of the IOSB. 


T.AST 


I. PRM 
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In a mapped system, the first word contains the relocation 
bias of the IOSB; the bias is, in effect, the number of the 
32-word block in which the IOSB starts. This block number is 
derived by viewing available real memory as a collection of 
32-word blocks numbered consecutively, starting with 0. 
Thus, if the I0SB starts at physical location 3210(octal), 
its block number is 32(octal). 


The second word is formatted as follows: 


Bits 0-5 Displacement in block (DIB) 
Bits 6-12 All zeros 
Bits 13-15 6 


The displacement in block is the offset from the bloc base. 
In the above example, in which the I0OSB starts at 
3210(octal), the DIB is equal to 10(octal). 


The value 6 in bits 13-15 is constant. It is used to cause 
an address reference through Kernel Address Page Register 6 
(APR6). Again, see Appendix A for details. 


Discussion of the address doubleword is deferred to an 
appendix because you seldom have to be concerned with its 


contents or format in writing a conventional driver. Its 
construction and subsequent manipulation are normally 
external to the driver. Subroutines are provided as 


Executive services for programmed I/0 to render’ the 
Manipulations of I/O transfers transparent to the driver 
itself. 


Driver access: 


Not referenced. 


Description: 


Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero. 


Driver access: 


Not initialized, read-only. 


Description: 


Device-dependent parameters constructed from the last six 
words of the DPB. Note that if the I/0 function is a 
transfer (refer to the description of D.MSK in Section 
4.1.2.1), the buffer address (first DPB device-dependent 
parameter) is translated to an equivalent address doubleword. 
Therefore, device-dependent parameter n is copied to I.PRM 
+(2*(n-1))+2, where n is the number of the parameter and the 
first parameter is numbered Pl. 
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4.1.1.2 The QIO Directive Parameter Block (DPB) - The QIO DPB is 
constructed as shown in Figure 4-2. 
The parameters in the DPB have the following meanings. 
Length (required): 


The length of the DPB, which for the RSX-11M QIO directive is 
always fixed at 12(decimal) words. 


‘DIC (required): 


Directive Identification Code. For the QIO directive, this value 
is l. For QIOW it is 3. 


Function Code (required): 


The code of the requested I/O function (0 through 31.). 
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Figure 4-2 QIO Directive Parameter Block (DPB) 


Modifier: 

Device-dependent modifier bits. 
Reserved: 

Reserved byte; must not be used. 
LUN (required): 

Logical Unit Number. 
Priority: 


Request priority. Ignored by RSX-11M. 


WRITING AN I/0 DRIVER--PROGRAMMING SPECIFICS 


EFN (optional): 


Event flag number. Zero indicates no event flag. If you spécify 
no event flag, QIOWS directives are converted to QIOS directives. 


I/O Status Block Address (optional): 
This word contains a pointer to the I/O status block, which is a 
2-word, device-dependent, I/O-completion data packet formatted 
as: 
Byte 0 
I/O status byte. 
Byte l 
Augmented data supplied by the driver. 
Bytes 2 and 3 
The contents of these bytes depend on the value of byte 0. 
If byte O equals 1, then these bytes usually contain the 
processed byte count. If byte 0 does not equal 0, then the 
contents are device-dependent. 
AST Address (optional): 
Address of an AST service routine. 
Device Dependent Parameters: 
Up to six parameters specific to the device and I/O function to 
be performed. Typically, for data transfer functions, the 
following four are used: 
e Buffer address 
e Byte count 
e Carriage control type 


e Logical block number 


The fields for any optional parameters not specified will be filled 
with zeros. 


4.1.2 The Device Control Block (DCB) 


Figure 4-3 is a schematic layout of the DCB. The DCB describes the 
Static characteristics of a device controller and the units attached 
to the controller. All fields must be specified except D.PCB, which 
is required only if you selected the loadable-driver option. 
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4.1.2.1 DCB Details - The fields in the DCB are described below: 
D.LNK (link to next DcB)l 
Driver access: 
Initialized, not referenced. 
Description: 


Address link to the next DCB. A zero in this field indicates 
the last (or only) DCB in the chain. 


D.UCB (pointer to first UCB) 
Driver access: 


Initialized, not referenced. 


D.UCBL Length of UCB 10 
° 

: 

° 

Legal function mask bits 16. - 31. 24 

: 

No-op function mask bits 16. - 31. 30 

x 

D.PCB H Address of partition control block 34 
BRS ae Sey te z pa 


Figure 4-3 Device Control Block 


1. Parenthesized phrases indicate value to be initialized in the data 
base source code. 
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Description: 
Address link to the U.DCB field of the first, and possibly 
the only, UCB associated with the DCB. For a given DCB, ali 
UCBs are in contiguous memory locations and must all have the 
same length. 

D.NAM (ASCII device name) 

Driver access: 

Initialized, not referenced. 


Description: 


Generic device name in ASCII by which device units are 
mnemonically referenced. 


D.UNIT (unit number range) 
Driver access: 
Initialized, not referenced. 
Description: 
Unit number range for the device. This range covers those 
logical units available to the user for device assignment. 
Typically, the lowest number is zero, and the highest is n-l, 
where n is the number of device-units described by the DCB. 
D.UCBL (UCB length) 
Driver access: 
Initialized, not referenced. 
Description: 
The UCB can have any length to meet the needs of the driver 
for variable storage. However, all UCBs for a given DCB must 


have the same length. The specified length must include the 
following prefix words if any or all are present: 


e U.I0c 
e U.ERHL 
e U.ERHC 
e U.ERSL 
e U.ERSC 
e U.LUIC 
e U.OWN 
e U.CLI 
e U.MUP 
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D.DSP (dispatch table pointer) 
Driver access: 
Initialized, not referenced. 
Description: 
Address of the driver dispatch table. 


When the Executive wishes to enter the driver at any of the 
four entry points contained in the driver dispatch table, it 
accesses D.DSP, locates the appropriate address in the table, 
and calls the driver at that address. A zero table address 
indicates that the (loadable) driver is not in memory. For a 
loadable driver, then, this field must be initialized to 
zero. If the driver does not process a given function, then 
this address points to a return instruction within the 
driver's code. 


You must provide a driver dispatch table in the driver 
source. The label on this table is of the form $xxTBL; it 
must be a global label. The designation xx is the 
2-character generic device name for the device. Thus, STTTBL 
is the global label on the driver dispatch table for the 
generic device name TT. This table is an ordered, 4-word 
table containing the following entry points: 


e I/0 initiator 
e Cancel I/0 

e Device timeout 
e Power failure 


When a driver is entered at one of these entry points, entry 
conditions are as follows: 


At initiator: 


If UC. QUE=1 
R5 UCB address 
R4 SCB address 
Rl Address of the I/O packet 


If Uc.QUE=0 
R5 = UCB address 


Interrupts are allowed. (UC.QUE is a bit in U.CTL in the 
UCB. See Section 4.1.4.1.) 


At cancel I/0: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

Rl = Address of TCB of current task 
RO = Address of active I/O packet 


Device interrupts at or below the priority of the 
requesting device are locked out. 
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At device time-out: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

R2 = Address of device CSR 

RO = I/O status code IE.DNR (Device Not Ready) 


Device interrupts at or below the priority of the 
requesting device are locked out. 


At power failure: 


R5 = UCB address 
R4 = SCB address 
R3 = Controller index 


Interrupts are allowed. The power failure entry point of 
a loadable driver is called by LOA only for units that are 
on line and have UC.PWF set. 


D.MSK (function masks) 
Driver access: 
Initialized, not referenced. 
Description: 


There are eight words, beginning at D.MSK, that are critical 
to the proper functioning of a device driver. The Executive 
uses these words to validate and dispatch the I/0 request 
specified by a QIO directive. Four masks, with two words per 
mask, are described by the bit configurations that you 
establish for these words: 


e Legal function mask 

e Control function mask 
e No-op function mask 

e ACP function mask 


The QIO directive allows for 32 possible I/O functions. The 
masks, as stated, are filters to determine validity and I/o 
requirements for the subject driver. 


The Executive filters the function code in the I/0 request 
through the four masks. The I/0 function code is the 
high-order byte of the function Parameter issued with the QIO 
directive. The decimal representation of that high-order 
byte is equivalent to the decimal bit number of the mask. If 
you want the function to be true in one of the four masks, 
you must set the bit in that mask in the position that 
numerically corresponds to the function code. For example, 
the code for IO.RVB is 2] (octal) and its decimal 
representation is 17, If you want I0.RVB to be true for a 
mask, you must set bit number 17(decimal) in the mask. 


The masks are laid out in memory in two 4-word groups. Each 
4-word group covers 16 function codes. The first 4 words 
cover the function codes 0-15; the second 4 word cover 
codes 16-31. Below is the layout used for the driver example 
in Section 6.2.2. 
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»WORD 140033 ;LEGAL FUNCTION MASK CODES 0-15. 
«WORD 30 ;CONTROL FUNCTION MASK CODES 0-15. 
«WORD 140000 :NO-OP FUNCTION MASK CODES 0-15. 
-WORD 0 ;ACP FUNCTION MASK CODES 0-15. 

»WORD 5 ;LEGAL FUNCTION MASK CODES 16.-31. 
-WORD 0 ;CONTROL FUNCTION MASK CODES 16.-31. 
»WORD 1 :NO-OP FUNCTION MASK CODES 16.-31. 
-WORD 4 ;ACP FUNCTION MASK CODES 16.-31. 


The mask words filter sequentially as follows: 
Legal Function Mask: 


Legal function values have the corresponding bit position in 
this word set to 1. Function codes that are not legal are 
rejected by QIO directive processing, which returns IE.IFC in 
the I/O status block, provided an IOSB address was specified. 


Control Function Mask: 


If any device-dependent data exists in the DPB, and this data 
does not require further checking by the QIO directive 
processor, the function is considered to be a _ control 
function. Such a function allows QIO directive processing to 
copy the DPB device-dependent data directly into the 1/0 
Packet. 


No-op Function Mask: 


A no-op function is any function that is considered 
successful as soon as it is issued. If the function is a 
no-op, QIO directive processing immediately marks the request 
successful; no additional filtering occurs. 


ACP Function Mask: 


If a function. code is legal but specifies neither a control 
function nor a no-op, then it specifies either an ACP 
function or a transfer function. If a function code requires 
intervention of an Ancillary Control Processor (ACP), the 
corresponding bit in the ACP function mask must be set. ACP 
function codes must have a value greater than 7. 


In the specific case of read-write virtual functions, you 
have the option to set the corresponding mask bits. If the 
corresponding mask bits for a read-write virtual function are 
set, Q10 directive processing recognizes that a file-oriented 
function is being requested to a non-file-structured device 
and converts the request to a read-write logical function. 


This conversion is particularly useful. Consider a 
read-write virtual function to a specific device: 


1. If the device is file structured and a file is open 
on the specified LUN, the block number specified is 
converted from a virtual block number in the file to 
a logical block number on the medium, and the request 
is queued to the driver as a read-write logical 
function. 
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2. If the device is file structured and no file is open 
on the specified LUN, then an error is returned and 
no further action is taken. 


3. If the device is not file Structured, then the 
request is simply transformed to a read-write logical 
function and is queued to the driver. (Specified 
block number is unchanged.) 


Transfer Function Processing: 


Finally, if the function is not an ACP function, then by 
default it is a transfer function. All transfer functions 
cause the QIO directive processor to check the specified 
buffer for legalit {that is, inclusion within the address 
space of the requesting task) and Proper alignment (word or 
byte). In addition, the processor checks the number of bytes 
being transferred for Proper modulus (that is, nonzero and a 
proper multiple). 


Creating Mask Words: 
Creating function mask words involves five steps: 


1. Establish the I/O functions available on the device 
for which driver support is to be provided. 


2. Build the legal function mask: Check the standard 
RSX-11M function mask values in Table 4-1 for 
equivalencies. Only the IO. KIL function is 
mandatory. IO.ATT and IO.DET functions, if used, 
must have the RSX-11M system interpretation. DIGITAL 
Suggests that functions having an RSX-11M system 
counterpart use the RSX-11M code, but this is 
required only when the device is to be used in 
conjunction with an ACP. From the supported function 
list in Table 4-1, you can build the two legal 
function mask words. 


3. Build the control function mask by asking: 


Does this function carry a standard buffer address 
and byte count in the first two device-dependent 
Parameter words? 


If it does not, then either it qualifies as a control 
function, or the driver itself must effect the 
checking and conversion of any addresses to the 
format required by the driver. See Section 6.3 for 
an example of a driver that does this. (Buffer 
addresses in Standard format are automatically 
converted to address doubleword format.) 


Control functions are essentially those functions 
whose DPBs do not contain buffer addresses or counts. 
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4, Create the no-op function mask by deciding which 
legal functions are to be set as no~-ops. Typically, 
for compatibility with File Control Services (FCS) or 
Record Management Services (RMS) on 
non-file-structured devices, the file access/deaccess 
functions are selected as legal functions, even 
though no specific action is required to access or 
deaccess a non-file-structured device; thus, the 
access/deaccess functions are set to be no-ops. 


5. Finally, include the ACP functions Write Virtual 
Block and Read Virtual Block for those drivers that 
support both read and write. (Include only one 
related ACP function if the driver supports only read 
or write.) 


D.PCB (Partition Control Block) 
Driver access: 
Initialized, not referenced. 
Description: 


Address of the driver's Partition Control Block (PCB). This 
word is present in the DCB if and only if the loadable-driver 
SYSGEN option has been selected. It must be initialized to 
zero. You can extend the DCB by adding words after D.PCB. 


A PCB exists for every partition in a system. MCR creates a 
PCB when the SET /MAIN or SET /SUB commands are given. If a 
driver is loadable, its PCB describes the partition in which 
it resides. 


The Executive uses D.PCB together with D.DSP (the address of 
the driver dispatch table) to determine whether a driver is 
loadable or resident, and, if loadable, whether it is in 
memory. Zero and nonzero values for these two pointers have 
the meanings shown in Table 4-l. 


Table 4-1 
D.PCB and D.DSP Bit Definitions 


Loadabie 
driver, 


Resident 


=0 . : 
not in driver 
memory 
(not Loadable 
#0 possible} driver, 


in memory 
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4.1.2.2 Establishing 1/0 Function Masks - Table 4-2 is supplied to 
assist you in determining the proper values to set in the function 
masks. The mask values are given for each I/O function used by 
DIGITAL-supplied drivers. The bit number allows you to determine 
which mask group to use: for bits numbered 0 through 15, use the mask 
value for a word in the first 4-word group; for bits numbered 16 
through 31, use the mask value for a word in the second 4-word group. 


Table 4-2 
Mask Values for Standard I/O Functions 


Bit Mask Related I/o 
# Value | Symbolic | Function | 


0 IO. KIL Cancel I/0 

al 2 IO.WLB Write Logical Block 

2 4 IO. RLB Read Logical Block 

3 10 IO.ATT Attach Device 

4 20 I0.DET Detach Device 

5 40 General Device Control 

6 100 General Device Control 

7 200 General Device Control 

8 Diagnostics 

9 IO. FNA Find File in Directory 

10 IO.ULK Unlock Block 

ll IO. RNA Remove File from Directory 
12 IO. ENA Enter File in Directory 

13 IO.ACR Access File for Read 
14 IO. ACW Access File for Read/Write 


IO.ACE Access File for Read/Write/Extend 


16 1 IO. DAC Deaccess File 
2 IO. RVB Read Virtual Block 
4 IO0.WVB Write Virtual Block 
10 IO. EXT Extend File 
20 I0.CRE Create File 
40 IO.DEL Mark File for Delete 
100 IO. RAT Read File Attributes 
200 IO.WAT Write File Attributes 
400 IO. APC ACP Control 
1000 Unused 
2000 Unused 
4000 Unused 
10000 Unused 
20000 Unused 
40000 Unused 
100000 Unused 


Of the function mask values listed in Table 4-2, only I0.KIL is 
mandatory and has a fixed interpretation. However, if IO.ATT and 
IO.DET are used, they must have the standard meaning. (Refer to the 
RSX-11M/M-PLUS 1/0 Drivers Reference Manual for a description of 
Standard 1/0 functions.) If QIO directive processing encounters a 
function code of 3 or 4 and the code is not set to be a no-op, QIO$ 
assumes that these codes represent Attach Device and Detach Device, 
respectively. The other codes are suggested but not mandatory. You 
are free to establish all other function-code values on 
non-file-structured devices. The mask words must reflect the proper 
filtering process. 
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If a driver is being written for a file-structured device, 
standard function mask values of Table 4-2 must be established. 


Tables 4-3, 4-4, and 4-5 are guides to determining the proper 


the 


bit 


masks for disks, tapes, and unit record devices (such as terminals, 


card readers, line printers, and paper tape puncheS/readers). 


Table 4-3 
Mask Word Bit Settings for Disk Drives 


RSX-11M 


Related 
Symbolic 


IO.KIL 
IO.WLB 
IO. RLB 
I0. ATT 
I0.DET 
I0.STC 


I0.CLN 
Diagnostic 
IO.FNA 
IO.ULK 
IO. RNA 
IO. ENA 
I0.ACR 
I0. ACW 
IO.ACE 


OWOANHAUPWNHEH OO 
nn 
ao 


o9oooa ow 


IO. DAC 
I0.RVB 
IO.WVB 
IQ. EXT 
I0.CRE 
I0.DEL 
IQ. RAT 
IO.WAT 
IO. APC 


ooo OOo ®@ 


transfer function, bit set only in legal 

function mask 

¢ -~ control function, bit set in legal and 
control function masks 

n - no-op function, bit set in legal and no-op 
function masks 

a - ACP function, bit set in legal and ACP 
function masks 

sa - special case, bit set only in ACP function 
mask, but not legal 

sd - special case, bit set only if diagnostic 
support in system and driver 
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Table 4-4 
Mask Word Bit Settings for Magnetic Tape Drives 


RSX-11M Related 


0 c ce IO. KIL 
1 t t IO.WLB 
2 t t Io. RLB 
3 c c IO.,ATT 
4 c c IO. DET 
5 c c I0.STC 
6 ¢ Cc 
7 sa I0.CLN 
8 sd sd Diagnostic 
9 a IO. FNA 
10 IO.ULK 
il TO. RNA 
12 n IO. ENA 
13 a n I0,.ACR 
14 a n IO. ACW 
15 a n IO. ACE 
16 a n TO. DAC 
17 a a IO. RVB 
18 a a IO.WVB 
19 a IO. EXT 
20 a I0.CRE 
21 I0.DEL 
22 a IO. RAT 
23 IO.WAT 
24 a i IO.APC 
25 | 
26 
27 
28 
29 
30 
31 


transfer function, bit set only in legal function 
mask 

control function, bit set in legal and control 
function masks 

no-op function, bit set in legal and no-op 
function masks 

ACP function, bit set in legal and ACP function 
masks 

special case, bit set only in ACP function mask, 
but not legal 

special case, bit set only if diagnostic support 
in system and driver 
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Table 4-5 
Mask Word Bit Settings for Unit Record Devices 


RSX-11M 


Related 
Symbolic 


IO.KIL 
I0.WLB 
IO. RLB 
I0.ATT 
I0.DET 
I0.STC 


QQ rra 


I0.CLN 
Diagnostic 
IO.FNA 
I0.ULK 
IO. RNA 
IO. ENA 
I0.ACR 
I0. ACW 
IO. ACE 


WODAIKDUBWHRO 
aun 
ao 


»9o 9 oO oo 


IO. DAC 
IO. RVB 
IO0.WVB 
I0. EXT 
I0.CRE 
IO. DEL 
IO. RAT 
IO.WAT 
I0. APC 


ooo nvomo om ow 


transfer function, bit set only in legal function 

mask 

| ¢ - control function, bit set in legal and _ control 

| function masks 

n - no-op function, bit set in legal and no-op 
function masks 

' a — ACP function, bit set in legal and ACP function 

| masks 

Isa - special case, bit set only in ACP function mask, 
but not legal 

sd - special case, bit set only if diagnostic support 
in system and driver 


WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS 


4.1.3 The Status Control Block (SCB) 


Figure 4-4 is a layout of the SCB. The SCB describes the status of a 
control unit that can run in parallel with all other control units. 


S.RCNT! a Offset to 1st He Number of registers E 
device register a to copy on error I 


i Saved 1/0 active bit map 
pointer to Error Message Block t 


F ! 
S.BMSK' ! 
; 0 
SHO Device 1/O queie 
listhead 2 
S.PRI i 
. ; * : : 4 
S.CTM Time-out count: 
ah 6 
S.ITM Initial Current 
S.CON 


SSTS Controller status 10 
. 
: 


S.MPR 


I 
i 
I--- Storage required for ---! 
l NPR UNIBUS devices ' 
ee with 22-bit addressing ---5 
1 


1. These offsets exist for mass storage devices only, and only in systems 


incorporating error logging. 
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4.1.3.1 SCB Details - The fields in the SCB are described below: 
S.RCNT (used for error logging) 
Driver Access: 
Not initialized, not referenced. 
Description: 
The number of registers to copy on error. This offset exists 
for mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging. 
S.ROFF (used for error logging) 
Driver Access: 
Not initialized, not referenced. 
Description: 
Offet to first device register. This offset exists for mass 
storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 
S.BMSV (used for error logging) 
Driver access: 
Not initialized, not referenced. 
Description: 
Saved I/O active bit map and pointer to Error Message Block. 
This offset exists for mass storage devices only (that is, 
when DV.MSD is set), and only in systems incorporating error 
logging. 
S.BMSK (used for error logging) 
Driver access: 
Not initialized, not referenced. 
Description: 
Device I/O active bit mask. This offset exists for mass 
Storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 
S.LHD (first word equals zero; second word points to first)1 


Driver access: 


Initialized, not referenced. 


1. Parenthesized contents indicate values to be initialized in the 
data base source code. 
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Description: 


Two words forming the I/O queue listhead. The first word 
points to the first I/O packet in the queue, and the second 
word points to the last I/0 packet in the queue. If the 
queue is empty, the first word is zero, and the second word 
points to the first word. 


S.PRI (device priority) 
Driver access: 


Initialized, read-only. 


Contains the priority at which the device interrupts. Use 
symbolic values (for example, PR4) to initialize this field 
in your data base source. You define these symbolic values 
by issuing the HWDDFS macro (refer to the sample data base in 
Section 6.2.1 and the listing of the HWDDF$ macro in Appendix 
Chg 


S.vVCT (interrupt vector divided by 4) 
Driver access: 
Initialized, not referenced. 
Description: 


Interrupt vector address divided by 4. For loadable drivers, 
the MCR/VMR LOA function uses this field and the existence of 
driver symbol(s) $xxINT, SxxINP, and $xxOUT to initialize the 
device interrupt vector. 


S.CTM (initialize to zero) 
Driver access: 
Not initialized, read-write. 
Description: 


RSX-11M supports device time-out, which enables a driver to 
limit the time that elapses between the issuing of an I/0 
operation and its termination. The current time-out count 
(in seconds) is initialized by moving S.ITM (initial time-out 
count) into S.CTM. The Executive clock service (in module 
TDSCH) examines active times, decrements them, and, if they 
reach zero, calls the driver at its device time-out entry 
point. 


The internal clock count is kept in 1-second increments. 
Thus, a time count of 1 is not precise because the internal 
clocking mechanism is operating asynchronously with driver 
execution. The minimum meaningful clock interval is 2 if you 
intend to treat time-out as a consistently detectable error 
condition. Note, if the count is 0, that no time-out occurs; 
a zero value is, in fact, an indication that time-out is not 
operative. The maximum count is 255. You are responsible 
for setting this field. Resetting occurs at actual time-out 
or within SFORK. 
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S.ITM (set to initial time-out count) 
Driver access: 
Initialized, read-only. 
Description: 
Contains the initial time-out value. 
§.CON (controller number times 2) 
Driver access: 
Initialized, read-only. 
Description: 


Controller number multiplied by 2. Drivers that are written 
to support more than one controller use this field. A driver 
May use S.CON to index into a controller table created and 
maintained internally by the driver itself. By indexing the 
controller table, the driver can service the correct 
controller when a device interrupts. See Section 4.2 for an 
example. 


S.STS (initialize to zero) 
Driver access: 
Initialized, not referenced. 
Description: 


Establishes the controller as busy/not busy (nonzero/zero). 
This byte is the interlock mechanism for marking a driver as 
busy for a specific controller. The byte is tested and set 
by SGTPKT and reset by SIODON. 


S.CSR (Control Status Register address) 
Driver access: 
Initialized, read-only. 
Description: 


Contains the address of the Control Status Register (CSR) for 
the device controller. The driver uses S.CSR to initiate I/0 
operations and to access, by indexing, other registers 
related to the device that are located in the I/O page. This 
address need not be a CSR; it need only be a member of the 
device's register set. It is accessed at system bootstrap 
time to determine if the interface exists on the system 
hosting the Executive. The Executive uses S.CSR to set the 
off-line bit at bootstrap so that system software can be 
interchanged between systems without an intervening system 
generation. The MCR LOA function also references S.CSR when 
it processes a loadable data base. Otherwise, only the 
driver itself accesses S.CSR. 
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S.PKT (reserve one word of storage) 
Driver access: 
Not initialized, read-only. 


Description: 


Address of the current I/O packet established by S$GTPKT. The 


Executive uses this field to retrieve the I/O packet 
upon the completion of an I/O request. S.PKT is not 
after the packet is completed. 
S.FRK (reserve four or five words of storage) 

Driver access: 
Not initialized, not referenced. 

Description: 
The four words starting at S.FRK are used for for 


storage if and when the driver deems it neces 
establish itself as a fork process. Fork block 


address 
zeroed 


k block 
sary to 
storage 


preserves the state of the driver, which is restored when the 


driver regains control at fork level. This a 
automatically used if the driver calls $FORK. 


The fork block is five words long instead of four 
conditions are met: 


1. Loadable drivers have been selected as a 
option. 


2. The system is mapped. 


rea is 


if two 


SYSGEN 


If these conditions are met, and the fork block is five words 


long, you must not use the fork block for any other 
In other words, you cannot share the space reserved 
fork block; if you attempt to do so, you will des 
loadable driver's relocation base. In addition, the 
fork block should always be part of the SCB if 
conditions above are met. 


S.MPR (reserve six words of storage) 
Driver access: 
Initialized, read-only. 


Description: 


purpose. 
for the 
troy the 

5-word 
the two 


Drivers use the six words starting at S.MPR for non-processor 


request (NPR) devices attached to a processor wit 
addressing. See Appendix B for details on init 
S.MPR. 


4.1.4 The Unit Control Block (UCB) 


Figure 4-5 is a layout of the UCB (a variable-length control 


One UCB exists for each nhvsical device-unit dqenerated into 


cists for each physical device-unit generated into 
configuration. For user-added drivers, this control block is 
as part of the source code for the driver data structure. 


h 22-bit 
ializing 


block). 
a system 


See 


defined 
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4.1.4.1 UCB Details - The fields in the UCB are described below. 
Note that the fields drawn with dotted outlines are not present in 
every UCB; their existence depends on physical device type, whether 
the system is generated with error logging, and whether you are 
running on a multiuser system. Refer to the individual descriptions 
of the offsets for details. 
U. IOC 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the total 
number of QIOs issued to the device. (Initialized to zero 
when device is mounted.) 
U.ERSL 
Device access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the maximum 
number of soft errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U.ERHL or in U.ERSL) is exceeded. 
U. ERHL 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the maximum 
number of hard errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U.ERHL or in U.ERSL) is exceeded. 
U.ERSC 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is’ set), 
and only in systems incorporating error logging: the total 


number of soft errors logged on the device. (Initialized ¢ 
zero when device is mounted.) 
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U.ERHC 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the total 
number of hard errors logged on the device. (Initialized to 
zero when device is mounted.) 
NOTE 
The following two symbolic names, U.MUP 
and U.CLI, both refer to the same 
absolute offset; use of the offset is 
dependent on system software 
configuration. Details regarding the 
use of each symbolic name are contained 
in the descriptions of U.MUP and U.CLI. 
U.MUP 
Driver access: 
Not initialized, not referenced. 
Description: 
For terminal UCBs only, and only in multiuser systems that 
include alternate CLI support: bits 1 to 4 contain an index 
to a table which contains the address of CLI Parser Block 
(CPB) for the current CLI; the remaining bits are used for 
other terminal-specific features, and defined as follows: 
UM.OVR Override CLI indicator 
UM.CLI CLI indicator 
UM.DSB Terminal disabled because CLI eliminated 
UM.NBR No broadcast 
U.CLI 
Driver access: 
Not initialized, not referenced. 
Description: 
For systems without alternate CLI support, but which do 
include multiuser protection: multiuser protection flag 
word. 
U.LUIC 
Driver access: 
Not initialized, not referenced. 
Description: 


For terminal UCBs only, and only in multiuser systems: the 
login UIC of the user at the particular terminal. 
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[ee pe oe oe ee 7 
——— — WOcount — — — — 4 
u.ioc4* 
yhoo - ~---- 
Here Hard error limit a Soft error limit 
UERSC! a pas See + Se a a See note 5 
: Hard e count Soft e t 
ey Beaks eh sid Lane hares on Wigs a 
U.MUP® Multiuser flags and CLI pointer 
po - = 
U.LUIC? Login UIC 
U.OWN! Owning terminal UCB address 
U.DCB _ Back pointer to DCB 
U.RED Redirect UCB pointer 
ae oe 
roa em 
U.CW1 Characteristics word 1 
U.CW2 Characteristics word 2 
U.CW3 Characteristics word 3 
U.CW4 Characteristics word 4 16 Alt 
devices 
U.SCB Pointer to SCB 20 
U.ATT | TCB address of attached task 22 
U.BUF Buffer relocation bias 24 
U.BUF+2 Buffer address 26 
32 


Device- 
dependent 


| storage | 


1. This offset appears only in multiuser systems. 


. These offsets appear only for terminal devices (that is, those devices that have DV.TTY 
set) in multiuser systems. 


. This offset appears only for terminal devices in multiuser systems that include alternate 
CLI support. In multiuser systems without alternate CLI support, this offset has a symbolic 
name of U.CLI. See descriptions and note in text. 


. These offsets appear only for mass storage devices (those devices that have DV.MSD set) 
in systems that employ error-logging. 


. These offsets are device-dependent. 
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U.OWN (initialize to zero) 
Driver access: 
Initialized, not referenced. 
Description: 


In multiuser systems only: the UCB address of the owning 
terminal for allocated devices. 


U.DCB (pointer to associated DCB) 
Driver access: 
Initialized, not referenced. 
Description: 
Backpointer to the corresponding DCB. Because the UCB is a 
key control block in the I/O data structure, access to other 
control blocks usually occurs by means of links implanted in 
the UCB. 
U.RED (redirect pointer--initialized to point to U.DCB of the UCB) 
Driver access: 
Initialized, not referenced. 
Description: 
Contains a pointer to the UCB to which this device-unit has 
been redirected. This field is updated as the result of an 
MCR Redirect command. The redirect chain ends when this word 
points to the beginning of the UCB itself (U.DCB of the UCB 
to be precise). 
U.CTL (set by you) 
Driver access: 
Initialized, not referenced. 
Description: 
U.CTL and the function mask words in the DCB drive QIoO 
directive processing. You are responsible for setting up 
this bit pattern. Any inaccuracy in the bit setting of U.CTL 
produces erroneous I/O processing. Bit symbols and their 
meanings are as follows: 
UC.ALG - Alignment bit. 
If this bit equals 0, then byte alignment of data buffers 
is allowed. If UC.ALG equals 1, then buffers must be 
aligned on word boundaries. 
UC. ATT - Attach/Detach notification. 
If this bit is set, then the driver is called when $GTPKT 
processes an Attach/Detach I/O function. Typically, the 
driver does not need to obtain control for Attach/Detach 


requests, and the Executive performs the entire function 
without any assistance from the driver. 


WRITING AN 1/0 DRIVER--PROGRAMMING SPECIFICS 


UC. KIL - Unconditional Cancel I/0 call bit. 


If set, the driver is called on a Cancel I/0 request, 
even if the unit specified is not busy. Typically, the 
driver is called on Cancel I/O only if an I/0 operation 
is in progress. 


UC.QUE - Queue bypass bit. 


If set, the QIO0 directive processor calls the driver 
prior to queuing the I/0 packet. After the processor 
makes this call, the driver is responsible for the 
disposition of the I/O packet. Typically, the processor 
queues an I/O packet prior to calling the driver, which 
later retrieves it by a call to SGTPRT. 


UC.PWF - Unconditional call on power failure bit. 


If set and the unit is on line, the driver is always to 
be called when the system is bootstrapped or power is 
restored after a power failure occurs. Typically, the 
driver is called on power restoration only when an I/0 
operation is in progress. Additionally, for loadable 
drivers, the driver is called when loaded if the unit is 
on line and UC.PWF is set. 


UC.NPR - NPR device bit. 


If set, the device is an NPR device. This bit determines 
the format of the 2-word address in U.BUF (details given 
in the discussion of U.BUF below). 


UC.LGH - Buffer size mask bits (2 bits). 


These two bits are used to check whether the byte count 
specified in an I/O request is a legal buffer modulus. 
You select one of the values below by ORing into the byte 
a 0, 1, or 3. 


00 - Any buffer modulus valid 

O01 - Must have word alignment modulus 

10 - Combination invalid 

11 - Must have doubleword alignment modulus 


UC.ALG and UC.LGH are independent settings. 
UC.ATT, UC.KIL, UC.QUE, and UC.PWF are usually zero, 
especially for conventional drivers. Every driver, however, 
must be concerned with its particular values for UC.ALG, 
UC.NPR, and UC.LGH. You are totally responsible for the 
values in these bits, and erroneous values are likely to 
produce unpredictable results. 
U.STS (initialize to zero) 
Driver access: 


Initialized, not referenced. 
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Description: 


This byte contains device-independent status information. 


The bit meanings are as follows: 
US.BSY - If set, device-unit is busy. 
US.MNT - If set, volume is not mounted. 
US.FOR - If set, volume is foreign. 
US.MDM - If set, device is marked for dismount. 
The unused bits in U.STS are reserved for system 
expansion. US.MDM, US.MNT, and US.FOR apply 
mountable devices. 
U.UNIT (unit number) 
Driver access: 
Initialized, read-only. 
Description: 


This byte contains the physical unit number 


use and 
only to 


the 


device-unit (that is, the value required for the hardware to 
access the specified drive unit). If the controller for the 
device supports only a single unit, the unit number is always 


zero. 
U.ST2 (set by you) 
Driver access: 
Initialized, not referenced. 
Description: 


This byte contains additional device-independent 
information. The bit meanings are as follows: 


status 


US.OFL - If set, the device is off line (that is, not in 


the configuration). 
US.RED -— If set, the device cannot be redirected. 
US.PUB - If set, the device is a public device. 


US.UMD 


If set, the device is attached for diagnostics. 


The remaining bits are reserved for system use and expansion. 


U.CW1 (set by you) 
Driver access: 


Initialized, not referenced. 
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Description: 


The first of a 4-word contiguous cluster of device 
characteristics information. U.CWl and U.CW4 are device 
independent. U.CW2 and U.CW3 are device dependent. The four 
characteristics words are retrieved from the UCB and placed 
in the requester's buffer on issuance of a Get LUN 
information (GLUNS) Executive directive. It is your 
responsibility to supply the contents of these four words in 
the assembly source code of the driver's data structure. 


U.CWl is defined as follows (If a bit is set to 1, the 
corresponding characteristic is true for the device.): 


DV.REC Bit 0--Record-oriented device 

DV.CCL Bit 1--Carriage-control device 

DV.TTY Bit 2--Terminal device 

DV.DIR Bit 3--Directory device 

DV.SDI Bit 4--Single directory device 

DV.SQD Bit 5--Sequential device 

DV.MSD Bit 6--Mass storage device 

DV.UMD Bit 7--Device supports user-mode diagnostics 

DV.EXT Bit 8--Device attached to a 22-bit direct addressing 
controller 

DV.SWL Bit 9--Unit is software write-locked 

DV.ISP Bit 10--Input spooled device 

DV.OSP Bit 1]1--Output spooled device 

DV.PSE Bit 12--Pseudo device 

DV.COM Bit 13--Device mountable as a communications channel 

DV.Fll Bit 14--Device mountable as a Files-11l device 

DV.MNT Bit 15--Device mountable 


U.CW2 (initialize to zero) 
Driver access: 
Initialized, read-write. 
Description: 


Specific to a given device driver (available for working 
storage or constants).1l 


U.CW3 (initialize to zero) 
Driver access: 
Initialized, read-write. 
Description: 


Specific to a given device driver (available for working 
storage or constants) .l 


1. Exception: for block-structured devices, U.CW2 and U.CW3 cannot be 
used for working storage. In drivers for block-structured devices 
(disks and DECtape), these two words must be initialized to a 
double-precision number givin the total number of blocks on the 
device. Place the high-order bits in the low-order byte of U.CW2 and 
the low-order bits in U.CW3. 
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For tape UCBs, the high and low bytes of this word specify 
the highest and lowest densities, respectively, supported by 
the device. Symbolic names for U.CW3 are defined as follows 
for tape UCBs: 
UN.UNS Unsupported/unspecified 
UD.200 200 bits/in, 7-track 
UD.556 556 bits/in, 7-track 
UD.800 800 bits/in, 7- or 9-track 
UD.160 1600 bits/in, 9-track 
UD.625 6250 bits/in, 9-track 
For example, a TE16 tape drive supports densities of both 800 
and 1600 bits/in. For a TE16 drive, U.CW3 would be coded as 
follows: 
» BYTE UD. 800,UD. 160 
U.CW4 (set by you) 
Driver access: 
Initialized, read-only. 
Description: 


Default buffer size. This word is changed by the MCR command 
SET /BUF. 


U.SCB (SCB pointer) 
Driver access: 
Initialized, read-only. 
Description: 
This field contains a pointer to the SCB for this UCB. In 
general, R4 contains the value in this word when the driver 
is entered by way of the driver dispatch table, because 
service routines frequently reference the SCB. 
U.ATT (initialize to zero) 
Driver access: 
Initialized, not referenced. 


Description: 


If a task has attached itself to the device-unit, this field 
contains its TCB address. 


U.BUF (reserve two words of storage) 
Driver access: 
Not initialized, read-write. 
Description: 


U.BUF labels two consecutive words that serve as a 


communication “region. between. SCTPKT and the driver. UsBUF; 
U.BUF+2, and U.CNT receive the first three words from the I/O 
packet. 
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For transfer operations, the format of these two words 
depends on the setting of UC.NPR in U.CTL. The driver does 
not format the words; all formatting is completed before the 
driver receives control. For unmapped systems, the first 
word is zero, and the second word is the physical address of 
the buffer. For mapped systems, the format is determined by 
the UC.NPR bit, which is set for an NPR device and reset for 
a program transfer device. 


The format for program transfer devices is identical to that 
for the second two words of I.IOSB in the I/O packet. See 
Section 4.1.1.1. 


In general, the driver does not manipulate these words when 
performing I/O to a _ program transfer device. Instead, it 
uses the Executive routines Get Byte, Get Word, Put Byte, and 
Put Word to effect data transfers between the device and the 
user's buffer. 


For NPR device drivers, the word layout is as follows: 


Word 1 

Bit 0 Go bit initially set to zero 
Bits 1-3 Function code-~-set to zeros 
Bits 4,5 Memory extension bits 

Bits 6 Interrupt enable--set to zero 


Bits 7-15 Zero 
Word 2 
Bits 0-15 Low-order 16-bits of physical address 


It is your responsibility to set the function code, interrupt 
enable, and go bits. This action must be accomplished by a 
Bit Set (BIS) instruction so that the extension bits are not 
disturbed. The driver must move these words into the device 
control registers to initiate the I/0 operation. 


Note that when the system is unmapped, bits 4 and 5 are 
always zero, but this fact is transparent to the driver. 
Thus, NPR device drivers are not cognizant of the mapping 
state in the system. 


The construction of U.BUF, U.BUF+2, and U.CNT occurs only if 
the requested function is a transfer function; if it is not, 
these three words contain the first three words of the I/0 
packet. 


The details of the construction of the address doubleword 
appear in Appendix A. 


U.CNT (reserve 1 word of storage) 
Driver access: 
Not initialized, read-write. 
Description: 
Contains the byte count of the buffer described by U.BUF. 


The driver uses this field in constructing the actual device 
request. 
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U.BUF and U.CNT keep track of the current data item in the 
buffer for the current transfer (except for NPR transfers). 
Because this field is being altered dynamically, the I/0 
packet may be needed to reissue an I/O operation, for 
instance, after a powerfail or error retry. 


Device-Dependent Words: 
Driver access: 
Not initialized, read-write. 
Description: 


You establish this variable-length block of words to suit 
device-specific requirements. 


4.1.5 The Device Interrupt Vector 


For resident drivers only, the device interrupt vector must be 
initialized when defining data structures, and must not be altered 
dynamically. This practice makes the driver code independent of 
device register address assignments and of the actual location of the 
interrupt vector. The driver data structure must include a_ storage 
assignment and initialization for the interrupt vector with the 
priority set to PR7. See lines 81 through 85 in Section 6.2.1 
(Section 6.2.1 contains the source code for the data structure of a 
sample resident driver). 


Writers of loadable drivers do not initialize the device interrupt 
vector. The vector is dynamically established by the MCR LOA command 
when the driver is loaded. When a driver is unloaded, the MCR. UNL 
command sets the vector to the system nonsense interrupt entry point. 


4.2 MULTICONTROLLER DRIVERS 


This section discusses the conditional code needed at the interrupt 
entry point of a driver that may handle one or several device 
controllers. This discussion leads to a description in the next 
section of the system macro INTSVS. INTSVS$ contains multicontroller 
conditionals and other features to simplify interrupt entry coding. 


Figure 4-6 shows the interrupt entry coding from the paper-tape-punch 
driver. This is an earlier version of the driver presented in its 
entirety in Section 6.2.2. 


The coding is conditionalized on PSSP11-1. The symbol PSS$P11 
represents the number of controllers and is set at SYSGEN. 


In a multicontroller device configuration, the controllers are 
numbered starting with 0. The code for a multicontroller driver 
contains a table (called CNTBL in the example in Figure 4-6) whose 
length in words is equal to the number of controllers. A number 
called the controller index--equal to the controller number’ times 
2--is stored in the SCB for each controller, in byte S.CON. 


When an I/O request occurs, and the driver is called at its initiator 
entry point, the driver first calls S$GTPKT to obtain an I/O packet to 
process. Among the values returned by S$GTPKT are the controller index 
(obtained from S.CON in the SCB) and the address of the UCB for the 
unit requesting I/O service. 
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The driver stores the requesting unit's UCB address in the controller 
table (CNTB1) at an offset equal to the controller index. Thus, for 
the driver at its interrupt entry point to access the requesting UCB, 
it needs simply to obtain the controller index. 


The controller index is obtained from the controller number, which is 
encoded in the lowest four bits of the PS word in the device's 
interrupt vector. At its interrupt entry point the driver first saves 
the PS (line 9. in Figure 4-6), which was set from the device's 
interrupt vector upon interrupt. The PS must be saved with the first 
instruction of interrupt code because its lower four bits are the 
processor condition code bits, which generally change after each 
instruction is issued. Later, after the call to $INTSV, the driver 
constructs the controller index from the saved PS (lines 17.-19.). It 
then uses this index to obtain the UCB address (line 20.). 


For single-controller devices, CNTBL is one word, TEMP is not needed 
to store the PS, and the UCB address is always the first (and only) 
entry in CNTBL. 


NOTE 


The code sequence used in the following 
example is not valid for a loadable 
driver. 


lo 7+ 

2 ; **-SPPINT-PC1l PAPER TAPE PUNCH CONTROLLER INTERRUPTS 

3.3 

4 

5 SPPINT:: 77;REF LABEL 

6 

7 ~IF GT PS$P11-1 

8 

9 MOV PS, TEMP 37 7SAVE CONTROLLER NUMBER 

10 

1l . IFTF 

12 

13 CALL SINTSV, PR4 7737SAVE REGISTERS AND SET PRIORITY 
14 

15 IFT 

16 

17 MOV TEMP, R4 77 ;RETRIEVE CONTROLLER NUMBER 
18 BIc #177760,R4 }37CLEAR ALL BUT CONTROLLER NUMBER 
19 ASL R4 77;7CONVERT TO CONTROLLER INDEX 
20 MOV CNTBL(R4),R5 ;;;RETRIEVE ADDRESS OF UCB 

21 

22 ~IFF 

23 

24 MOV CNTBL,RS 37; RETRIEVE ADDRESS OF UCB 

25 

26 -« ENDC 


Figure 4-6 Conditional Code for a Multicontroller Driver 
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4,3 THE INTSVS MACRO 


INTSVS is a system macro that minimizes coding differences between 
loadable and resident drivers. INTSV$ contains conditionally 
assembled code to handle: 


e Single or multiple controllers 

e lLoadable or resident drivers 

e@ Mapped or unmapped systems 
You can replace all the code in Figure 4-6 between lines 7 and 26 with 
the INTSV$ macro (as is done in the sample driver illustrated in 
Section 6.2.2). This is required for loadabie drivers on mapped 
systems, because interrupts from hardware devices must be processed in 
kernel address space. In particular, the decoding of the PS word and 
the call to SINTSV must be done before entering the driver. Thus, a 
call to the Executive routine SINTSV within a loadable driver is 
illegal, and the MCR LOA function returns an error if loading is 
attempted. 
When the INTSV$ macro is used for a loadable driver in a mapped 
system, the code from lines 9 to 19 inclusive (Figure 4-6) is not 
assembled as part of the driver. Instead, the LOA function allocates 
a block of dynamic memory in kernel address space to contain the 
interrupt coding. This block, called the Interrupt Control Block 
(ICB), also contains coding to perform the following: 

1. Save the kernel mapping (APR5) 

2. Load APR5 to map the driver 

3. Transfer to the driver 

4, Restore the mapping after return 


The LOA function also sets up the controller's interrupt vector so 
that hardware interrupts point to the ICB. 


Finally, using the INTSVS macro in a loadable driver on a mapped 
System requires that the symbol LDSxx (where xx is the 2-character 


device mnemonic) be defined either in the driver source or the 
assembly prefix file RSXMC.MAC, 


4.3.1 Format 
The format of the INTSV$ macro is: 
INTSVS xx,pri,nctlr[,pssave,ucbsave] 
XX 
The 2-character device mnemonic. 
pri 


The priority of the device (the priority that would be used in a 
call to SINTSV). 
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netlr 
The number of controllers the driver services. 
pssave 


An optional argument specifying a variable in which to save the 
PS word. If omitted, a variable named TEMP is used. 


ucbsave 


An optional argument specifying a block of contiguous words in 
which to retrieve the interrupting device's UCB address. If 
omitted, a block of contiguous words named CNTBL is used. 


Outputs: R4 is the controller index, only if nctlr is greater than 
1. 


R5 is the UCB address. 
Example: 
INTSVS PP,PR4,PSS$P11 
This usage of INTSV$ would effectively replace lines 7 through 26 in 


Figure 4-6. (PSSP11l is a symbol equated to the number of 
controllers.) 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


This section contains the Executive routines typically used by I/0 
drivers. They are listed in alphabetical order. The descriptions are 
taken directly from the source code for the associated services. 


We describe only the most widely used subroutines. Many other 
Executive service subroutines are available in modules IOSUB.MAC, 
EXESB.MAC, MEMAP.MAC, SYSXT.MAC, QUEUE.MAC, CORAL.MAC, and REQSB.MAC 
in UFD [11,10]. 


5.1 SYSTEM STATE REGISTER CONVENTIONS 


In system state, R5 and R4 are, by convention, nonvolatile registers. 
This means that an internally called routine is required to save and 
restore these two registers if the routine destroys their contents. 
R3, R2, Rl, and RO are volatile registers and may be used by a called 
routine without save and restore responsibilities. 


When a driver is entered directly from an interrupt, it is operating 
at interrupt level, not at system state. At interrupt level, any 
register the driver uses must be saved and restored. INTSVS preserves 
R5 and R4 for the driver's use. 


A routine may violate these conventions as long as an explicit 
statement exists in the program preface detailing the departure from 
conventions. Such departures should generally be avoided; they 
should be employed only when you can demonstrate that a departure from 
convention can improve overall system performance. 


See D.DSP in Section 4.1.2.1 for the contents of registers when a 
driver is entered. 


5.2 CONDITIONAL ROUTINES 


Two of the routines (SGTWRD and S$PTWRD) discussed in this chapter 
normally are assembled conditionally out of the Executive code. If a 
user-written driver requires either of these routines, the appropriate 
question must be answered affirmatively in the system generation 
dialog. See the descriptions of SGTWRD and $PTWRD below. 


5.3 SERVICE CALLS 


In the following descriptions, the file names mentioned are source 
modules found on the Executive source disk as [11,10]filnam.MAC. 
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$ACHKB/S$ACHCK 


ADDRESS CHECK 
These routines are in the file EXESB. A driver may call either 
routine to address-check a task buffer while the task is the current 
task. The SACHKB and SACHCK routines are normally used only by 
drivers setting UC.QUE in U.CTL. See Section 6.3 for an example. 
Calling sequences: 
CALL SACHKB 
or 


CALL SACHCK 


Description: 


+ 


**-SACHKB-ADDRESS CHECK BYTE ALIGNED 
**-SACHCK-ADDRESS CHECK WORD ALIGNED 


THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE 
WHETHER IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK. 


INPUTS: 


RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED. 
R1I=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES. 


OUTPUTS: 


C=1 IF ADDRESS CHECK FAILED, 
C=0 IF ADDRESS CHECK SUCCEEDED. 


RO AND R3 ARE PRESERVED ACROSS CALL. 


me Me Me te Me Me Se Oe Ne Ne Se Ne Me Se Ne He te Me Ne 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$ALOCB 


ALLOCATE CORE BUFFER 
This routine is in the file CORAL. 
Calling sequences: 
CALL SALOCB 
or 


CALL SALOC1 


+ 


**-SALOCB-ALLOCATE CORE BUFFER 
**—~SALOC1-ALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO ALLOCATE AN EXEC CORE BUFFER. THE 
ALLOCATION ALGORITHM IS FIRST FIT AND BLOCKS ARE ALLOCATED IN 
MULTIPLES OF FOUR BYTES. 


INPUTS: 


RO=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT SALOC1. 
R1=SIZE OF THE CORE BUFFER TO ALLOCATE IN BYTES. 


OUTPUTS: 


C=1 IF INSUFFICIENT CORE IS AVAILABLE TO ALLOCATE THE BLOCK. 
C=0 IF THE BLOCK IS ALLOCATED, 

RO=ADDRESS OF THE ALLOCATED BLOCK. 

R1=LENGTH OF BLOCK ALLOCATED. 
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$ASUMR 


ASSIGN UNIBUS MAPPING REGISTERS 
This routine is in the file MEMAP,. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/0 driver. 
Rather, it is called from within the SSTMAP routine. Refer to 
Appendix B for a discussion. 
Calling sequence: 

CALL SASUMR 


Description: 


+ 


**-SSASUMR-ASSIGN UNIBUS MAPPING REGISTERS 


THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR'S. NOTE THAT 
FOR THE SAKE OF SPEED, THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK 
POINTS TO THE UMR ADDRESS (2ND) WORD OF THE BLOCK, NOT THE FIRST WORD. 
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF 
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE 
FIRST UMR ASSIGNED AND THE NUMBER OF UMR'S ASSIGNED TIMES 4, THE 
BLOCKS ARE LINKED IN THE ORDER OF INCREASING FIRST UMR ADDRESS. 


INPUTS: 
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RO=POINTER TO A MAPPING REGISTER ASSIGNMENT BLOCK. 
M.UMRN(RO)=NUMBER OF UMR'S REQUIRED * 4, 


OUTPUTS: 
ALL REGISTERS ARE PRESERVED. 


C=0 IF THE UMR'S WERE SUCCESSFULLY ASSIGNED. 
ALL FIELDS OF THE MAPPING REGISTER ASSIGNMENT BLOCK 
ARE INITIALIZED AND THE BLOCK IS LINKED INTO 
THE ASSIGNMENT LIST. 
C=1 IF THE UMR'S COULD NOT BE ASSIGNED. 
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$CLINS 


CLOCK QUEUE INSERTION 
This routine is in the file QUEUE. 
Calling Suwanee? 

CALL $CLINS 


Description: 


+ 


**-SCLINS-CLOCK QUEUE INSERTION 


THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. THE ENTRY 
IS INSERTED SUCH THAT THE CLOCK QUEUE IS ORDERED IN ASCENDING TIME, 
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST, 


INPUTS: 


RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK. 
R1=HIGH ORDER HALF OF DELTA TIME. 

R2=LOW ORDER HALF OF DELTA TIME, 

R4=REQUEST TYPE. 

R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER, 


OUTPUTS: 


THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING 
TO THE TIME THAT IT WILL COME DUE. 
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$DEACB 


DEALLOCATE CORE BUFFER 


This routine is in the file CORAL. 


Calling sequences: 
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CALL SDEACB 
or 


CALL $DEAC1 


+ 


**-SDEACB-DEALLOCATE CORE BUFFER 
**-~SDEACI1-DEALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO DEALLOCATE AN EXEC CORE BUFFER. THE BLOCK 
IS INSERTED INTO THE FREE.BLOCK CHAIN BY CORE ADDRESS. IF AN 
ADJACENT BLOCK IS CURRENTLY FREE, THEN THE TWO BLOCKS ARE MERGED 
AND INSERTED IN THE FREE BLOCK CHAIN. 


INPUTS: 
RO=ADDRESS OF THE CORE BUFFER TO BE DEALLOCATED. 
R1=SIZE OF THE CORE BUFFER TO DEALLOCATE IN BYTES. 
R3=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT SDEACI. 


OUTPUTS: 


THE CORE BLOCK IS MERGED INTO THE FREE CORE CHAIN BY CORE 
ADDRESS AND IS MERGED IF NECESSARY WITH ADJACENT BLOCKS. 
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$DEUMR 


DEASSIGN UNIBUS MAPPING REGISTERS 
This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when. 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/O driver. 
Rather, it is called from within the SIODON routine. Refer to 
Appendix B for a discussion. 
Calling sequence: 

CALL SDEUMR 


Description: 


+ 


**-SDEUMR-DEASSIGN UNIBUS MAPPING REGISTERS 

THIS ROUTINE IS CALLED TO DEASSIGN A CONTIGUOUS BLOCK OF UMR'S. IF 
THE MAPPING ASSIGNMENT BLOCK IS NOT IN THE LIST, NO ACTION IS TAKEN. 
NOTE THAT FOR THE SAKE OF ASSIGNMENT SPEED, THE LINK WORD POINTS TO 
THE UMR ADDRESS (2ND) WORD OF THE ASSIGNMENT BLOCK. 


INPUTS: 
R2=POINTER TO ASSIGNMENT BLOCK, 


OUTPUTS: 


RO AND R1 ARE PRESERVED. 
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$DVMSG 


DEVICE MESSAGE OUTPUT 
This routine is in file EXESB. 
Calling sequence: 

CALL SDVMSG 


Description: 


+ 


**-SDVMSG-DEVICE MESSAGE OUTPUT 


THIS ROUTINE IS CALLED TO SUBMIT A MESSAGE TO THE TASK TERMINATION 
NOTIFICATION TASK. MESSAGES ARE EITHER DEVICE RELATED OR A 
CHECKPOINT WRITE FAILURE FROM THE LOADER. 


INPUTS: 


RO=MESSAGE NUMBER. 
R5=ADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO. 


OUTPUTS: 


A FOUR WORD PACKET IS ALLOCATED, RO AND R5 ARE STORED IN THE 
SECOND AND THIRD WORDS, RESPECTIVELY, AND THE PACKET IS 
THREADED INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE 
QUEUE. 


NOTE: IF THE TASK TERMINATION NOTIFICATION TASK IS NOT 
INSTALLED OR NO STORAGE CAN BE OBTAINED, THEN THE 
MESSAGE REQUEST IS IGNORED. 
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Note: 
Drivers use only two codes in calling $DVMSG: T.NDNR (device not 
ready), and T.NDSE (select error). SDVMSG can be set up and 
called as follows: 
MOV #T.NDNR, RO 


or 


MOV #T.NDSE, RO 
CALL SDVMSG 


EXECUTIVE 
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$SEXRQP 


EXECUTIVE REQUEST WITH QUEUE INSERT BY PRIORITY 


This routine is in the file REQSB. SEXROQP requests the execution of a 
task after inserting a packet into the receive list of the task. 


Calling sequence: 
CALL SEXROQP 


Description: 


+ 


**—-SEXROP-EXECUTI VE 
*#*—SEXROF -EXECUTIVE 
**—SEXRON -EXECUTI VE 
**—-SEXROQU-EXECUTI VE 
**-SEXROS—-EXEC UTI VE 


THE EXECUTIVE 


INPUTS: 


OUTPUTS: 
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REQUEST WITH QUEUE INSERT BY PRIORITY 
REQUEST WITH QUEUE INSERT FIFO 

REQUEST WITH NO QUEUE INSERTION 

UNSTOP AND REQUEST WITH NO QUEUE INSERTION 
REQUEST WITH NO CONDITIONAL SCHEDULE REQUEST 


THESE ROUTINES PROVIDE A STANDARD INTERFACE TO ALL TASKS REQUESTED BY 


RO=TCB ADDRESS OF TASK TO REQUEST 
R1=ADDR OF PACKET TO QUEUE TO TASK (IF ENTRY AT SEXROP/SEXROF) 


C=0 IF THE REQUEST WAS SUCCESSFULLY COMPLETED. 
C=1 IF THE TASK WAS NOT SUCCESSFULLY REQUESTED, 
Z=0 IF PCB ALLOCATION FAILURE, 
Z=1 IF TASK ACTIVE, BEING REMOVED, OR BEING FIXED. 
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$FORK 


FORK 

This routine is in the file SYSXT. A driver calls S$FORK to switch 
from a partially interruptable level (its state following a call on 
SINTSV) to a fully interruptable level. 

Calling sequence: 


CALL SFORK 


Description: 


+ 


**-SFORK-FORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS CALLED FROM AN I/O DRIVER TO CREATE A SYSTEM PROCESS THAT 
WILL RETURN TO THE DRIVER AT STACK DEPTH ZERO TO FINISH PROCESSING, 


; 

; 

i 

; 

i 

i 

; INPUTS: 

; 

; R5=ADDRESS OF THE UCB FOR THE UNIT BEING PROCESSED. 

é 

; OUTPUTS: 

: 

; REGISTERS R5 AND R4 ARE SAVED IN THE CONTROLLER FORK BLOCK AND 
i A SYSTEM PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK 
H QUEUE AND A JUMP TO SINTXT IS EXECUTED. 

i- 

Notes: 


1. S$FORK cannot be called unless SINTSV has been previously 
called. The fork-processing routine assumes that S$INTSV has 
set up entry conditions. 


2. A driver's current time-out count is cleared in calls to 
SFPORK. This protects the driver from synchronization 
problems that can occur when an I/O request and the time-out 
for that request happen at the same time. After a return 
from a call to S$FORK, a driver's time-out code will not be 
entered. 


If the clearing of the time-out count is not desired, a 
driver has two alternatives: 


a. Perform time-out operations by directly inserting 
elements in the clock queue (refer to the description of 
the SCLINS routine). 


b. Perform necessary initialization, including clearing 
S.STS in the SCB to zero (establishing the controller as 
not busy), and call the $FORK1 routine rather than S$FORK. 
Calling S$FORK] bypasses the clearing of the current 
time-out count. 


3. The driver must not have any information on the stack when 
SFORK is called. 


FORK] 
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SFORK1 


This routine is in the file SYSXT. A driver calls S$FORK1 to bypass 
the clearing of its time-out count when it switches from a partially 
interruptable level to a fully interruptable level (refer also to the 
description of the $FORK routine). 


Calling sequence: 


CALL SFORK1 


Description: 


me Ne te te te Ne 8 Se Me Ne Ne Ne NO Ne Me Ne MO 


Notes: 


**-SPORK1-FORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND 
SAVE REGISTER R5. 


INPUTS: 


R4=ADDRESS OF THE LAST WORD OF A 3 WORD FORK BLOCK PLUS 2. 
R5=REGISTER TO BE SAVED IN THE FORK BLOCK. 


OUTPUTS: 


REGISTER R5 IS SAVED IN THE SPECIFIED FORK BLOCK AND A SYSTEM 
PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK QUEUE 
AND A JUMP TO SINTXT IS EXECUTED. 


For mapped systems with loadable driver support, a 5-word 
fork block is required for calls to $FORK1. 


When a 5-word fork block is used, the driver must initialize 
the fifth word with the base address (in 32-word blocks) of 
the driver partition. This address can be obtained from the 
fifth word of the standard fork block in the SCB. 


The driver must not have any information on the stack when 
SFORK1 is called. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTBYT 


GET BYTE 


This routine is in the file BFCTL. SGTBYT manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling sequence: 
CALL SGTBYT 


Description: 


+ 


**-SGTBYT-GET NEXT BYTE FROM USER BUFFER 
THIS ROUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK, AFTER THE BYTE HAS BEEN 
FETCHED, THE NEXT BYTE ADDRESS IS INCREMENTED. 
INPUTS: 

RS=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 


OUTPUTS: 
THE NEXT BYTE IS FETCHED FROM THE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK. THE NEXT BYTE ADDRESS IS 
INCREMENTED. 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 


me Ne Ne Se Ne Ne te Se Se Ne Ne Ne Se Ne Ne Ne Me Me Ne 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTPKT 


GET PACKET 


This routine is in the file IOSUB. 


Calling sequence: 


CALL SGT PKT 


Description: 


we Ne me Se Se Me Se Ne Ne Me Ne Ne Se Se Me Ne Se Ne Ne 


me Me Ne Se Me we Se te 


+ 


**-SGTPKT-GET I/O PACKET FROM REQUEST QUEUE 


THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O 
REQUEST TO PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY 
SET INDICATION IS RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO 
DEQUEUE THE NEXT REQUEST FROM THE CONTROLLER QUEUE. IF NO REQUEST 
CAN BE DEQUEUED, THEN A CARRY SET INDICATION IS RETURNED TO THE 
CALLER. ELSE THE CONTROLLER IS SET BUSY AND A CARRY CLEAR 

INDICATION IS RETURNED TO THE CALLER. 


INPUTS: 
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO GET A PACKET FOR, 
OUTPUTS: 


C=l IF CONTROLLER IS BUSY OR NO REQUEST CAN BE DEQUEUED. 
C=0 IF A REQUEST WAS SUCCESSFULLY DEQUEUED.,. 
R1=ADDRESS OF THE I/O PACKET. 
R2=PHYSICAL UNIT NUMBER. 
R3=CONTROLLER INDEX, 
R4=ADDRESS OF THE STATUS CONTROL BLOCK. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 


NOTE: R4 AND R5 ARE DESTROYED BY THIS ROUTINE. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTWRD 


GET WORD 


This routine is in the file BFCTL. $GTWRD manipulates words U.BUF and 
U.BUF+2 in the UCB, and is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN when the following question is asked: 

*26. Include routine S$GTWRD? [Y/N]: 


If an LPAl1 device (LA:) is included in your system, the S$GTWRD 
routine is automatically included and Question 26 is not asked. 


Calling sequence: 
CALL SGTWRD 


Description: 


+ 


**k-SGTWRD-GET NEXT WORD FROM USER BUFFER 
THIS ROUTINE IS CALLED TO GET THE NEXT WORD FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE WORD HAS BEEN 
FETCHED, THE NEXT WORD ADDRESS IS CALCULATED. 
INPUTS: 

R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
OUTPUTS: 


THE NEXT WORD IS FETCHED FROM THE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK. THE NEXT WORD ADDRESS IS CALCULATED. 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SINTSV 


INTERRUPT SAVE 
This routine is in the file SYSxXT. 
Calling sequence: 


CALL SINTSV, PRn 


Description: 


+ 


**-SINTSV-INTERRUPT SAVE 


THIS ROUTINE IS CALLED FROM AN INTERRUPT SERVICE ROUTINE WHEN AN 
INTERRUPT IS NOT GOING TO BE IMMEDIATELY DISMISSED. A SWITCH TO 

THE SYSTEM STACK IS EXECUTED IF THE CURRENT STACK DEPTH IS +l. WHEN 
THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS, 
JUMPS TO SINTXT, OR EXECUTES A RETURN. 


INPUTS: 


4(SP)=PS WORD PUSHED BY INTERRUPT. 
2(SP)=PC WORD PUSHED BY INTERRUPT. 
0(SP)=SAVED R5 PUSHED BY 'JSR R5,SINTSV'. 
0(R5)=NEW PROCESSOR PRIORITY. 


OUTPUTS: 


REGISTER R4 IS PUSHED ONTO THE CURRENT STACK AND THE CURRENT 
STACK DEPTH IS DECREMENTED. IF THE RESULT IS ZERO, THEN 

A SWITCH TO THE SYSTEM STACK IS EXECUTED. THE NEW PROCESSOR 
STATUS IS SET AND A CO-ROUTINE CALL TO THE CALLER IS EXECUTED. 


me we Me Se me me Be Ne Te NO Ne MO Me Me Te Ne Ne Me Ne te Ne te te 


Note: 


A system macro, INTSVS, is provided to simplify the coding of 
standard interrupt entry processing. See Section 4.3. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SINTXT 


INTERRUPT EXIT 
This routine is in the file SYSXT. 
Calling sequence: 
JMP SINTXT 
or 
RETURN (if a call to SINTSV has been executed) 


Description: 


+ 


**-SINTXT-INTERRUPT EXIT 


THIS ROUTINE IS CALLED VIA A RETURN TO EXIT FROM AN INTERRUPT. IF THE 
STACK DEPTH IS NOT EQUAL TO ZERO, THEN REGISTERS R4 AND R5 ARE 
RESTORED AND AN RTI IS EXECUTED. ELSE A CHECK IS MADE TO SEE 

IF THERE ARE ANY ENTRIES IN THE FORK QUEUE. IF NONE, THEN R4 AND 

R5 ARE RESTORED AND AN RTI IS EXECUTED. ELSE REGISTERS R3 THRU 

RO ARE SAVED ON THE CURRENT STACK AND A DIRECTIVE EXIT IS EXECUTED. 


INPUTS: (MAPPED SYSTEM) 
06(SP)=PS WORD PUSHED BY INTERRUPT. 
04(SP)=PC WORD PUSHED BY INTERRUPT. 
02(SP)=SAVED R5. 
00(SP)=SAVED R4. 

INPUTS: (REAL MEMORY SYSTEM) 


NONE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SIOALT/SIODON 


I/O DONE ALTERNATE ENTRY and I/0 DONE 
These routines are in the file IOSUB. 


Calling sequences: 


CALL STOALT 
CALL STODON 
Description: 
+ 


**-SIOALT-I/O DONE (ALTERNATE ENTRY) 
**-STODON-I/O DONE 


THIS ROUTINE IS CALLED BY DEVICE DRIVERS AT THE COMPLETION OF AN I/O REQUEST 
TO DO FINAL PROCESSING, THE UNIT AND CONTROLLER ARE SET IDLE AND SIOFIN IS 
ENTERED TO FINISH THE PROCESSING, 
INPUTS: 
RO=FIRST I/O STATUS WORD. 
R1=SECOND I/O STATUS WORD. 
R2=STARTING AND FINAL ERROR RETRY COUNTS IF ERROR LOGGING DEVICE. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED. 


NOTE: IF ENTRY IS AT SIOALT, THEN Rl IS CLEARED TO SIGNIFY THAT THE 
SECOND STATUS WORD IS ZERO. 


OUTPUTS: 
THE UNIT AND CONTROLLER ARE SET IDLE. 


R3=ADDRESS OF THE CURRENT I/O PACKET. 


me te Me te Ne Ne Se He Ne Me Te Ne te Ne Se Ne Se NO Se Ne He Me te Me 


NOTE 


R4 is destroyed when either of these 
routines is called. The routines call 
SIOFIN, which destroys R4. 


These routines push the address of 
routine S$DQUMR onto the stack before 
returning to the driver. This precludes 
the use of the stack for temporary data 
storage by drivers when calling these 
routines. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SIOFIN 


I/O FINISH 


This routine is in the file IOSUB. Most drivers do not call S$IOFIN, 
but you should be aware that this routine is executed when a driver 
calls $IOALT or S$IODON. A driver that references an I/O packet before 
it is queued (bit UC.QUE set--see Section 6.3 for an example) calls 
SIOFIN if the driver finds an error while preprocessing the I/0 
packet. 


Calling sequence: 
CALL SIOFIN 


Description: 


+ 


**-STOFIN-I/O FINISH 


THIS ROUTINE IS CALLED TO FINISH I/O PROCESSING IN CASES WHERE THE UNIT AND 
CONTROLLER ARE NOT TO BE DECLARED IDLE. 


INPUTS: 
RO=FIRST I/O STATUS WORD. 
R1=SECOND I/O STATUS WORD. 
R3=ADDRESS OF THE I/O REQUEST PACKET. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 
OUTPUTS: 
THE FOLLOWING ACTIONS ARE PERFORMED: 


1-THE FINAL I/O STATUS VALUES ARE STORED IN THE I/O STATUS BLOCK IF 
ONE WAS SPECIFIED. 


2-THE I/O REQUEST COUNT IS DECREMENTED. IF THE RESULTANT COUNT IS 
ZERO, THEN 'TS.RDN' IS CLEARED IN CASE THE TASK WAS 
STOPPED FOR I/O RUNDOWN. 


3-IF 'TS.CKR' IS SET, THEN IT IS CLEARED AND CHECKPOINTING OF THE 
TASK IS INITIATED. 


4-IF AN AST SERVICE ROUTINE WAS SPECIFIED, THEN AN AST IS QUEUED 
FOR THE TASK. ELSE THE I/O PACKET IS DEALLOCATED. 


5-A SIGNIFICANT EVENT OR EQUIVALENT IS DECLARED. 


NOTE: R4 IS DESTROYED BY THIS ROUTINE. 
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EXECUTIVE SERVICES AVAILABLE TO I/0 DRIVERS 


$MPUBM 


MAP UNIBUS TO MEMORY 

This routine is in the file MEMAP, SMPUBM is used only for NPR 
devices requiring UNIBUS Mapping Registers, when 22-bit memory 
addressing is enabled. See Appendix B for a discussion. 

Calling sequence: 


CALL SM PUBM 


Description: 


+ 


**—-SMPUBM-MAP UNIBUS TO MEMORY 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEM- 
ORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. 

INPUTS: 


R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB. 


OUTPUTS: 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE TRANSFER 
ARE LOADED. 


NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 


Ne Ne Ne Me we Ne We Ne Me Se te Ne te Te Ne NO Ne Se Ne 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


S$MPUB1 


MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 
This routine is in file MEMAP. It is used only for NPR devices that 
require UNIBUS Mapping Registers, support parallel operations, and 
have 22-bit memory addressing enabled. See Appendix B for a 
discussion of using this routine. 
Calling sequence: 

CALL SMPUB1 


Description: 


+ 


**-SMPUB1-MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN 

MEMORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. THIS ALTERNATE 
ENTRY POINT ALLOWS THE DRIVER TO SPECIFY A NON-STANDARD UMR MAPPING 
ASSIGNMENT BLOCK, 


INPUTS: 
RO=ADDRESS OF A UMR MAPPING ASSIGNMENT BLOCK 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 


OUTPUTS: 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE 
TRANSFER ARE LOADED 
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NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$PTBYT 


PUT BYTE 


This routine is in the file BFCTL. SPTBYT manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling sequence: 
CALL SPTBYT 


Description: 


+ 


**-SPTBYT-PUT NEXT BYTE IN USER BUFFER 


ese Ne we 


THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN 

USER BUFFER. AFTER THE BYTE HAS BEEN STORED, THE NEXT BYTE ADDRESS 
IS INCREMENTED. 

INPUTS: 


R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS, 
2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER, 


OUTPUTS: 


THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK. THE NEXT BYTE ADDRESS IS INCREMENTED, 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$PTWRD 


PUT WORD 
This routine is in the file BFCTL. $PTWRD manipulates words U.BUF and 
U.BUF+2 in the UCB. $PTWRD is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN to the following question: 

*27. Include routine $PTWRD? [Y/N]: 
If an ADO1 A/D controller device ({AF:) or an AFCll A/D controller 
device (AF:) is included in your system, the $PTWRD routine is 
automatically included and Question 27 is not asked. 

Do you intend to include a user written driver? [Y/N]: 
Calling sequence: 

CALL SPTWRD 


Description: 


+ 
**-S$PTWRD-PUT NEXT WORD IN USER BUFFER 


ue 


THIS ROUTINE IS CALLED TO PUT A WORD IN THE NEXT LOCATION IN 

USER BUFFER. AFTER THE WORD HAS BEEN STORED, THE NEXT WORD ADDRESS 
IS CALCULATED. 

INPUTS: 


R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
2(SP)=WORD TO BE STORED IN THE NEXT LOCATION OF THE BUFFER. 


OUTPUTS: 


THE WORD IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK, THE NEXT WORD ADDRESS IS CALCULATED, 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 


we te te Ne me te te Ne A NO Me Ne te SE Ne Se Ne Ne 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$QINSP 


QUEUE INSERTION BY PRIORITY 
This routine is in the file QUEUE. A driver may call S$QINSP to insert 
into the I/O queue an I/O packet that the Executive has not already 
placed in the queue. SQINSP is used only by drivers setting UC.QUE in 
U.CTL. See Section 6.3 for an example. 
Calling sequence: 

CALL SQINSP 


Description: 


+ 


**-SQINSP-QUEUE INSERTION BY PRIORITY 
THIS ROUTINE IS CALLED TO INSERT AN ENTRY IN A PRIORITY ORDERED 
LIST. THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A 
LOWER PRIORITY OR THE END OF THE LIST IS REACHED. THE NEW 
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT. 
INPUTS: 

RO=ADDRESS OF THE TWO WORD LISTHEAD. 

R1=ADDRESS OF THE ENTRY TO BE INSERTED. 
OUTPUTS: 

THE ENTRY IS LINKED INTO THE LIST BY PRIORITY. 


RO AND R1 ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


S$QRMVF 


QUEUE REMOVAL FROM FRONT OF LIST 
This routine is in the file QUEUE. 
Calling sequence: 

CALL SQRMVF 


Description: 


+ 


**-~SORMVG-QUEUE REMOVAL FROM FRONT OF LIST 


THIS ROUTINE IS CALLED TO REMOVE THE NEXT (FRONT) ENTRY FROM A 
LIST. THE LIST ORGANIZATION MAY BE EITHER FIFO OR BY PRIORITY. 


INPUTS: 
RO=ADDRESS OF THE TWO WORD LISTHEAD. 
OUTPUTS: 
C=l1 IF THERE ARE NO ENTRIES IN THE LIST. 
C=0 IF THE NEXT ENTRY IS REMOVED FROM THE LIST. 
R1=ADDRESS OF THE ENTRY REMOVED. 


RO IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$RELOC 


RELOCATE 
Relocate is in the file MEMAP, A driver may call $RELOC to relocate a 
task virtual address while the task is the current task. Relocate is 
normally used only by drivers setting UC.QUE in U.CTL. See Section 
6.3 for an example. 
Calling Sequence: 

CALL SRELOC 


Description: 


+ 


**~SRELOC-RELOCATE USER VIRTUAL ADDRESS 


THIS ROUTINE IS CALLED TO TRANSFORM A 16 BIT USER VIRTUAL ADDRESS 
INTO A RELOCATION BIAS AND DISPLACEMENT IN BLOCK RELATIVE TO APR6. 


INPUTS: 
RO=USER VIRTUAL ADDRESS TO RELOCATE, 
OUTPUTS: 


R1=RELOCATION BIAS TO BE LOADED INTO PAR6. 
R2=DISPLACEMENT IN BLOCK PLUS 140000 (PAR6 BIAS). 


RO AND R3 ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$STMAP 


SET UP UNIBUS MAPPING ADDRESS 


This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. See Appendix B for a discussion. 


Calling sequence: 


CALL SSTMAP 


Description: 
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+ 


**-SSTMAP-SET UP UNIBUS MAPPING ADDRESS 


THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO SET UP THE 
UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR'S. IF THE UMR'S 
CANNOT BE ALLOCATED, THE DRIVER'S MAPPING ASSIGNMENT BLOCK IS PLACED 
IN A WAIT QUEUE AND A RETURN TO THE DRIVER'S CALLER IS EXECUTED. THE 
ASSIGNMENT BLOCK WILL EVENTUALLY BE DEQUEUED WHEN THE UMR'S ARE 
AVAILABLE AND THE DRIVER WILL BE REMAPPED AND RETURNED TO WITH R1-R5 
PRESERVED AND THE NORMAL OUTPUTS OF THIS ROUTINE. THE DRIVER'S 
CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHILE IT IS 
BLOCKED AND IN THE WAIT QUEUE. ONCE A DRIVER'S MAPPING ASSIGNMENT 
BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS NOT REMOVED FROM THE 
QUEUE UNTIL THE UMR'S ARE SUCCESSFULLY ASSIGNED. THIS STRATEGY 
ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER'S 
WITH LARGE REQUESTS FOR UMR'S WILL NOT WAIT INDEFINITELY. 


INPUTS: 


R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB. 
(SP)=RETURN TO DRIVER'S CALLER. 


OUTPUTS: 


UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE 
ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB. 


NOTE: REGISTERS Rl, R2, AND R3 ARE PRESERVED ACROSS CALL. 


NOTE 


This routine pushes the address of 
routine $DQUMR+2 onto the stack before 
returning to the caller. A driver, 
therefore, should not use the stack for 
temporary data storage when calling this 
routine. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


S$STMP1 


SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 
This routine is in file MEMAP. It is used only for NPR devices that 
require UNIBUS Mapping Registers, support parallel operations, and 


have enabled 22-bit memory addressing. See Appendix B for a 
discussion of using this routine. 


Calling sequence: 
CALL SSTMP1 
Description: 
+ 


**-SSTMP1-SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 


A UMR MAPPING ASSIGNMENT BLOCK AND CONTEXT STORAGE BLOCK, IN 
THE SAME MANNER AS SSTMAP USES THE FORK BLOCK AND MAPPING 


3 

; 

7 

; THIS ENTRY CODE SETS UP AN ALTERNATE DATA STRUCTURE USED AS 
; 

; 

; BLOCK IN THE SCB. THE FORMAT OF THE STRUCTURE IS AS FOLLOWS: 


w-------------------- 4 WORDS USED FOR SAVING 
! DRIVER'S CONTEXT IN CASE 
! UMR'S CAN'T BE MAPPED 

! IMMEDIATELY. 
! 


6 WORDS USED AS A UMR 
MAPPING ASSIGNMENT BLOCK. 


INPUTS: 
RO=ADDRESS OF THE DATA STRUCTURE DEPICTED ABOVE 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 

OUTPUTS: 


DATA STRUCTURE POINTERS SET UP FOR ENTRY TO SSTMP2 IN $STMAP 


me Se we Ne te Ne Ne NO Ne Ne Ne Ne Ne we NO Me HE Se NO Se We Se SH Se Ne Ne 


NOTE 


This routine pushes the address of 
routine S$DQUMR+2 onto the stack before 
returning to the caller. A driver, 
therefore, should not use the stack for 
temporary data storage when calling this 
routine. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$SWSTK 


SWITCH STACKS 


This routine is in the file SYSXT. 


Calling sequence: 


SWSTKS label 


The special macro in RSXMC.MAC must be used. 


Description: 


we Ne Re Te Me Me MO Te me Me te te Ne me Me Ne te Te He Me Me Ne Ne Ne Ne Se Ne Se Ne Ne we Te HE NO NO Ne NP Ne Ne NO Ne NE Ne Te Ne Se 


+ 


**SSWSTK-SWITCH STACKS 


THIS ROUTINE IS CALLED FROM TASK LEVEL TO SWITCH TO THE SYSTEM 
STACK THUS INHIBITING TASK SWITCHING. THE CALLING TASK MUST BE 
PRIVILEGED IF RUNNING IN A MAPPED SYSTEM AND MAPPED TO THE EXEC. 
CONTROL IS PASSED HERE FROM DRDSP AFTER THE TRAP HAS OCCURRED AND 
SDIRSV HAS BEEN CALLED. 


CALLING SEQUENCE: 


EMT 376 ;TRAP TO SEMSST IN DRDSP 
«WORD ADDR ;ADDRESS FOR RETURN TO USER STATE 


INPUTS AT THIS POINT: 
R3=ADDRESS OF PC WORD OF TRAP ON STACK + 2 
MAPPED SYSTEM: 


22(SP)=PS PUSHED BY TRAP 

20(SP)=PC PUSHED BY TRAP 

16(SP)=SAVED R5 

14(SP)=SAVED R4 

12(SP)=SAVED R3 

10(SP)=SAVED R2 

06(SP)=SAVED Rl 

04(SP)=SAVED RO 

02(SP)=RETURN ADDRESS FOR SYSTEM EXIT 
00 (SP)=104376 


UNMAPPED SYSTEM: 


10(SP)=SAVED R3 
06(SP)=SAVED R2 
04(SP)=SAVED Rl 
02(SP)=SAVED RO 
00(SP)=RETURN ADDRESS FOR SYSTEM EXIT 


OUTPUTS: 
THE USER IS CALLED BACK ON THE SYSTEM STACK WITH ALL REGISTERS 


PRESERVED. TO RETURN TO TASK LEVEL THE CALLER MERELY EXECUTES 
A RETURN. 


Note: Task registers are not modified. 
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CHAPTER 6 


INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES 


The first example that follows illustrates the procedures required to 
add a resident driver and resident data base to an RSX-11M system so 
that they can run on a system without support for loadable drivers and 
without muitiuser protection. The driver in the example supports the 
punch capability of the PC1l Paper Tape Reader/Punch. 


Section 6.3 gives a coding example from a resident driver that 
inhibits the automatic packet queuing in QIO processing in order to 
address-check and relocate a special user buffer. 


In addition to the examples shown in this chapter, you should review 
the source code for one or more standard DIGITAL-supplied drivers. 
Also, examine file SYSTB.MAC, which contains data structures created 
by SYSGEN. 


6.1 DEVICE DESCRIPTION 


The PCll Paper Tape Reader/Punch is capable of reading 8-hole, 
unoiled, perforated paper tape at 300 char/s, and punching tape at 50 
char/s. The system consists of a paper tape reader/punch and 
controller. A unit containing only a reader (PR11) is also available. 


In reading tape, a set of photodiodes translates the presence or 
absence of holes in the tape to logic levels representing ones and 
zeroes. In punching tape, a mechanism translates logic levels 
representing ones and zeroes to the presence or absence, respectively, 
of holes in the tape. Any information read or punched is 
parallel-transferred through the controller. When an address is 
placed on the UNIBUS, the controller decodes the address and 
determines if the reader or punch has been selected. If one of the 
four device register addresses has been selected, the controller 
determines whether an input or an output operation should be 
performed. An input operation from the reader is initiated when the 
processor transmits a command to the paper tape reader status 
register. An output operation is initiated when the processor 
transfers a byte to the paper tape punch buffer register. 


The controller enables the PDP-ll system to control the reading or 
punching of paper tape in a flexible manner. The reader can be 
operated independently of the punch; either device can be under 
direct program control or can operate without direct supervision 
(through the use of interrupts) so as to maintain continuous 
operation. 


INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES 


6.2 DATA BASE AND DRIVER SOURCE 
The simplicity of writing a conventional driver for RSX-11M is 
obscured by the volume of explanation required to cover the universal 


case. As you will see below, building a conventional driver is a 
straightforward and modest undertaking. 


6.2.1 The Data Base 
The resident data base source shown below is self-explanatory. Take 
Special note of the legal function mask words, starting at line 45. 
The standard function codes listed in Table 4-1 were used in creating 
the mask. Thus, the punch driver accepts the following I/O functions: 

e Cancel I/O (CAN) 

e Write Logical Block (WLB) 

e Attach Device (ATT) 

e Detach Device (DET) 

e Access File For Read/Write (ACW) 

e Access File For Read/Write/Extend (ACE) 

@ Deaccess File (DAC) 


e Write Virtual Block (WVB) 


The CAN function is mandatory. The WLB function is the only transfer 
function actually supported. 


The ATT and DET functions are control functions. The three ATT/DET 
functions are legal for FCS and RMS compatibility, but are set to be 
no-ops. The WVB function is legal but is converted to WLB by QI0 
directive processing. 


The bit mask for each function is as follows: 


Function Function Code(octal) Mask(octal) Bit Range(decimal) 


CAN 0 000001 0-15. 
WLB 1 000002 0-15. 
ATT 3 000010 0-15. 
DET 4 000020 0-15. 
ACW 16 040000 0-15. 
ACE 17 100000 0-15. 
DAC 20 000001 16.-3i. 
WVB 22 000004 16.-31. 


The legal masks result from adding the 0-15(decimal) bit-range words 
to form a mask and all the 16-3l(decimal) bit-range words to form the 
second mask. 


The control, no-op, and ACP masks are created in an analogous fashion, 
matching bit positions with legal function code meanings. 


The complete set of mask words appears on lines 45 through 52 in the 
data structure source. 
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The function code selections for record-oriented devices are intended 
to match FCS and RMS requirements for file-structured devices. When 
FCS or RMS executes an Access For Write, it is simply marked as a 
no-op. This tends to minimize FCS and RMS device-dependent logic. 
Note also on line 84 that the controller number, which is encoded in 
the low byte of the interrupt vector PS word in RSX-11M, is set to 
zero. Finally, since the code represents a reSident data base, note 
that lines 78 through 85 would be omitted for a loadable data base. 


1 - TITLE USRTB 

2 - IDENT /01/ 

3 

4; 

5 : COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 

6 ; 

7 ; THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
8 ; ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 

9 ; OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
10 ; AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC. 

ll; 

12 ; THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
13 ; NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
14 ; EQUIPMENT CORPORATION. 

15 ; 

16 ; DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 

17 ; OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC, 

18 ; 
19 ; VERSION 01 

20 3; 

21; T. J. PASCUSNIK 25-NOV-74 

22 ; 

23 ; CONTROL BLOCKS FOR PAPER TAPE PUNCH DRIVER 

24; 

25 ; MACRO LIBRARY CALLS 

26 ; 

27 
28 »MCALL DCBDFS,HWDDFS 
29 DCBDFS ;DEFINE DEVICE CONTROL BLOCK OFFSETSL 
30 HWDDF S$ ;DEFINE HARDWARE REGISTERS 

31 

32 ; 

33 ; PAPER TAPE PUNCH DEVICE DATA BASE 

34 ; 

35 ; PAPER TAPE PUNCH DEVICE CONTROL BLOCK 

36 ; 

37 SUSRTB:: 

38 PPDCB: »~WORD 0 ;LINK TO NEXT DCB 

39 »~WORD - PPO ;POINTER TO FIRST UCB 

40 ~ASCII /PP/ ;DEVICE NAME 
41 BYTE 0,0 ;LOWEST AND HIGHEST UNIT NUMBERS COVERED 
42 : BY THIS DCB 

43 ~WORD PPND-PPST ;LENGTH OF EACH UCB IN BYTES 
44 «WORD SPPTBL 7;POINTER TO DRIVER DISPATCH TABLE 
45 -~WORD 140033 ;LEGAL FUNCTION MASK CODES 0-15. 
46. «WORD 30 ;CONTROL FUNCTION MASK CODES 0-15, 


1. Appendix C lists all macros that exist in RSX-11M to generate 
control block offsets. 
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47 ~WORD 140000 ;NO-P'ED FUNCTION MASK CODES 0-15. 

48 »~WORD 0 ;ACP FUNCTION MASK CODES 0-15. 

49 ~WORD 5 ;LEGAL FUNCTION MASK CODES 16.-31. 

50 ~WORD 0 ;CONTROL FUNCTION MASK CODES 16.-31. 
51 ~WORD 1 :NO-OP'ED FUNCTION MASK CODES 16.-31. 
52 ~WORD 4 ;ACP FUNCTION MASK CODES 16.-31. 

53 : 

54 ; PAPER TAPE PUNCH UNIT CONTROL BLOCK 

55 ; 

56 .PPO:: 

57 PPST=. 

58 ~WORD PPDCB ;BACK POINTER TO DCB 

59 ~WORD ~-2 ;POINTER TO REDIRECT UNIT UCB 

60 ~ BYTE uc. ATT, 0 :CONTROL PROCESSING FLAG (PASS CONTROL 
61 : ON ATTACH/DETACH), UNIT STATUS 

62 . BYTE 0,0 ;PHYSICAL UNIT NUMBER, UNIT STATUS EXTENS ION 
63 «WORD DV. REC ;FIRST DEVICE CHARACTERISTICS WORD 

64 3 (RECORD-ORIENTED DEVICE) 

65 ~WORD 0 :;SECOND DEVICE CHARACTERISTICS WORD 
66 ; (FOR INTERNAL USE BY DRIVER) 

67 ~WORD 0 :;THIRD DEVICE CHARACTERISTICS WORD 

68 H (FOR INTERNAL USE BY DRIVER) 

69 ~WORD 64. ;FOURTH DEVICE CHARACTERISTICS WORD 
70 . (DEFAULT BUFFER SIZE IN BYTES) 

71 ~WORD PPSCB ;POINTER TO SCB 

72 ~WORD 0 ;TCB ADDRESS OF ATTACHED TASK 

73 -BLKW 1 ;RELOCATION BIAS OF BUFFER OF CURRENT 
74 . I/O REQUEST 

75 ~ BLKW 1 ;ADDRESS OF BUFFER OF CURRENT I/O REQUEST 
76 » BLKW 1 ;BYTE COUNT OF CURRENT I/O REQUEST 

77 PPND=. 

78; 

79 ; PAPER TAPE PUNCH INTERRUPT VEC TOR 

80 ; 

81 ~ASECT 

82 .=74 

83 ~WORD SPPINT ;ADDRESS OF INTERRUPT ROUTINE 

84 ~WORD PR7!0 ; INTERRUPT AT PRIORITY 7 (CONTROLLER=0 ) 
85 -PSECT 

86 : 

87 ; PAPER TAPE PUNCH STATUS CONTROL BLOCK 

88 ; 

89 PPSCB: «WORD 0 ;CONTROLLER I/O QUEUE LISTHEAD 

90 : (POINTER TO FIRST ENTRY) 

91 -WORD «72 7 (POINTER TO LAST ENTRY) 

92 BYTE PR4,74/4 ;DEVICE PRI, INTERRUPT VECTOR ADDRESS/4 
93 ~BYTE 0,4 ;CURRENT AND INITIAL TIMEOUT COUNTS 
94 ~ BYTE 0,0 ;CONTROLLER INDEX AND STATUS 

95 H (O=IDLE, 1=BUSY) 

96 »~WORD 177554 ;ADDRESS OF CONTROL STATUS REGISTER 
97 » BLKW 1 :ADDRESS OF CURRENT I/O PACKET 

98 ~ BLKW 4 ;FORK BLOCK ALLOCATION 

99 
100 . END 


6.2.2 Driver Code 


The code shown below for the punch capability of the PCll is typical 
for a conventional driver. In fact, many of the descriptive comments 
can be used as a template and easily tailored to a driver for another 
device. 
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The structure of the driver follows the standard RSX-11M form, being 
separated into processing code for the following: 


e@ Initiator 
e Power failure 
e Interrupt 
e Time-out 
e Cancel I/0 
The driver itself services only Write Logical, Attach, and Detach I/0 


functions. Attach and Detach result in the punching of 170. nulls 
each for header and trailer. 


Power failure and cancel I/O are handled by means of device time-out, 
as is the device-not-ready condition. 


The driver uses the following Executive services: 


SINTXT 
SGT PKT 
SGTBYT 
$DVMSG 


SINTSV is used indirectly; it is called by INTSV$ (line 165). See 
Section 4.3. 


Comments beginning with ';;;' indicate that the instruction is being 
executed at a priority level greater than or equal to 4. 


The code contained in lines 139-141 is used to inhibit the punching of 
a trailer on ATT/DET if the task is being aborted. This is especially 
desirable when the device is not ready (for example, out of paper 
tape) and the system has generated the DET function for the aborting 
process. 


l. -TITLE PPDRV 
2. -IDENT /02/ 


3. 

4, ;3 

5. 3; COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 
6. ; 

7. ; THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
8. ; ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 
9. ; OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
10. ; AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC, 

A ee 
12. ; THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
13. ; NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
14. ; EQUIPMENT CORPORATION. 

LB ot 

16. ; DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 
17. ; OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC. 
18. ; 

19. ; VERSION 02 
20. ; 

Zi. 7 T. J. PASCUSNIK 25-NOV-74 

22. 3 
23. 3; MODIFIED BY: 

24. ; 
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25. ; C. A. ANDERS 15-MAR-76 

26. 3 

27. 3 CA001 -- ADDITION OF LOADABLE DRIVER SUPPORT. 

28. ; 

29. : T. J. PASCUSNIK 4-APR-76 

30. ; 

31. 3 TPQ031 -- EXECUTIVE DATA STRUCTURE CHANGES. 

32. 3 

33. ; 

34. ; PCll PAPER TAPE PUNCH DRIVER 

35. 3 

36. ; MACRO LIBRARY CALLS 

i ee 

38. 

39. «MCALL ABODFS, HWDDF$, PKTDF$, TCBDF$ 

40. ABODFS ;DEFINE TASK ABORT CODES 

41. HWDDFS ;DEFINE HARDWARE REGISTER SYMBOLS 

42. PKTDFS ;DEFINE I/0 PACKET OFFSETS 

43. TCBDFS$ ;DEFINE TASK CONTROL BLOCK OFFSETS 

44, 

45. 3 

46. ; EQUATED SYMBOLS 

47. 3 

48. ; PAPER TAPE PUNCH STATUS WORD BIT DEFINITIONS (U.CW2) 

49. ; 

50. 

51. WAIT=100000 ;WAITING FOR DEVICE TO COME ON-LINE (1=YES) 
52. ABORT=40000 ;ABORT CURRENT I/O REQUEST (1=YES) 

53. TRAIL=200 ;CURRENTLY PUNCHING TRAILER (1=YES) 

54. 

55. 3 

56. ; LOCAL DATA 

57. ¢ 

58. ; CONTROLLER IMPURE DATA TABLES (INDEXED BY CONTROLLER NUMBER) 

59. 7 

60. 

61. CNTBL: - BLKW PSSP11 ;ADDRESS OF UNIT CONTROL BLOCK 

62. 

63. 

64. -IF GT P$SP1l1-1 

65. 

66. TEMP: . BLKW 1 ;TEMPORARY STORAGE FOR CONTROLLER NUMBER 
67. 

68. » ENDC ; CAO00] 

69. ; CAOO] 

70. 

Tle. 3 

72. 3; DRIVER DISPATCH TABLE 

730 7 

74. 

75. $PPTBL:: -WORD PPINI ;DEVICE INITIATOR ENTRY POINT 

76. ~WORD PPCAN , ;CANCEL I/O OPERATION ENTRY POINT 

77. ~WORD PPOUT ;DEVICE TIMEOUT ENTRY POINT 

78. ~WORD PPPWF ;POWERFAIL ENTRY POINT 

79. 

80. 7+ 

81. ; **-PPINI-PC1l PAPER TAPE PUNCH CONTROLLER INITIATOR 

82. 3 

83. ; THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 
84. ; IS QUEUED AND AT THE END OF A PREVIOUS I/0 OPERATION TO PROPAGATE THE EXECU- 
85. ; TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT 
86. ; IS MADE TO DEQUEUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS 
87. ; EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPER- 
88. ; ATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED. 


89, 

90. 

91. 

92. 

93. 

94. 

95. 

96. 

97. 

98. 

99. 
100. 
101. 
102. 
103. 
104. 
105. 
106. 
107. 
108. 
109. 
110. 
lll. 
112, 
113. 
114, 
115. 
116. 
117. 
118. 
119, 
120. 
121. 
122, 
123. 
124, 
125, 
126. 
127. 
128, 
129, 
130. 
131. 
132. 
133. 
134. 
135. 
136. 
137. 
138, 
139. 
140. 
141. 
142, 
143. 
144, 
145, 
146. 
147. 
148. 
149, 
150. 
U5. 
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INPUTS: 


OUTPUTS: 


me Se Ne Se Me Se Ne Se Se Ne te 


R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 


IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT- 
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER- 
ATION IS INITIATED, 


-ENABL LSB 


PPINI: CALL 
BCS 


WD. 
WD. 
WD. 
WD. 
wD. 
WD. 
WD. 
WD. 
WD. 
WD. 
wD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 


NANO Ne Me me Me we we te Ne me te Se Se Se Se te Me Se Se Se Se Ne Ne te Ne te te Ne 


MOV 
CLR 
CMPB 
BEQ 
MOV 
BIT 
BNE 
BIS 


MOV 
108: BIS 
TST 
BMI 
20S: BIC 
MOVB 
MOV 


00 


SGT PKT ;GET AN I/O PACKET TO PROCESS 
PPPWF 7IF CS CONTROLLER BUSY OR NO REQUEST 


THE FOLLOWING ARGUMENTS ARE RETURNED BY SGTPKT: 


R1=ADDRESS OF THE I/O REQUEST PACKET 

R2=PHYSICAL UNIT NUMBER OF THE REQUEST UCB. 
R3=CONTROLLER INDEX. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED, 


PAPER TAPE PUNCH I/O REQUEST PACKET FORMAT: 


-- I/O QUEUE THREAD WORD. 

~- REQUEST PRIORITY, EVENT FLAG NUMBER. 

-- ADDRESS OF THE TCB OF THE REQUESTER TASK. 

-- POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER, 

-- CONTENTS OF THE FIRST LUN WORD IN REQUESTER TASK HEADER (UCB). 
-- I/O FUNCTION CODE (IO.WLB, IO.ATT OR IO.DET). 

-- VIRTUAL ADDRESS OF I/O STATUS BLOCK. 

-- RELOCATION BIAS OF I/O STATUS BLOCK, 

-~ I/O STATUS BLOCK ADDRESS (REAL OR DISPLACEMENT + 140000). 
-- VIRTUAL ADDRESS OF AST SERVICE ROUTINE. 

-- RELOCATION BIAS OF I/O BUFFER. 

~- BUFFER ADDRESS OF I/O TRANSFER. 

-- NUMBER OF BYTES TO BE TRANSFERED, 

-- NOT USED. 


- NOT USED. 
- NOT USED. 


-- NOT USED. 


R5, CNTBL (R3) ;SAVE UCB POINTER FOR INTERRUPT ROUTINE 
U.CW2(R5) ;CLEAR ALL SWITCHES 

I.FCN+1 (R1),#IO.WLB/256. ;WRITE LOGICAL BLOCK FUNCTION? 
10s ;IF EQ YES 


I.TCB(R1),RO ;GET REQUESTOR TCB ADDRESS 
#T2.ABO,T.ST2(RO) ;TASK BEING ABORTED? 7 TPO31 
65$ ;IF NE YES - DON'T PUNCH TRAILER 


#TRAIL,U.CW2(R5) ;OTHERWISE FUNCTION IS ATTACH OR DETACH 
; SET FLAG TO PUNCH TRAILER 

#170.,U.CNT(R5) ;SET COUNT FOR 170 NULLS 

#WAIT,U.CW2(R5) ;ASSUME WAIT FOR DEVICE OFF LINE 

@S.CSR(R4) ;DEVICE OFF LINE? 

80S ;IF MI YES 

#WAIT,U.CW2(R5) ;DEVICE ON LINE, CLEAR WAIT CONDITION 

S.ITM(R4),S.CTM(R4) ;SET TIMEOUT COUNT 

#100,@S.CSR(R4) ;ENABLE INTERRUPTS 
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152. ; 

153. ; POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND THEREFORE CAUSES 
154. ; NO IMMEDIATE ACTION ON THE DEVICE. THIS IS DONE TO AVOID A RACE CONDITION 
155. ; THAT COULD EXIST IN RESTARTING THE I/O OPERATION 

156. ; 

157. 

158.  PPPWF: RETURN : 

159. 

160. ;+ 

161. 3; **-SPPINT-PC11 PAPER TAPE PUNCH CONTROLLER INTERUPTS 

162, ;- 

163. 

164, SPPINT:: 37 ;REF LABEL 

165. INTSVS PP,PR4,P$$P11 37;GENERATE INTERRUPT SAVE CODE ; CAOO1 
166. MOV U.SCB(R5),R4 3737GET ADDRESS OF STATUS CONTROL BLOCK 
167. MOVB S.ITM(R4) ,S.CTM(R4) 33 ;RESET TIMEOUT COUNT 

168. MOV S.CSR(R4),R4 +3;;POINT R4 TO CONTROL STATUS REGISTER 
169. MOV (R4)+,U.CW3(R5) 37;SAVE STATUS 

170. BMI 60$ 373¢1F MI, ERROR 

171. SUB #1,U.CNT(R5) 3;DECREMENT CHARACTER COUNT 

172. Bcs 50$ 77¢1F CS, THEN DONE 

173. TSTB U.CW2(R5) +7;CURRENTLY PUNCHING TRAILER? 

174, BPL 308 3771F PL NO 

175. CLRB (R4) 37 ;LOAD NULL INTO OUTPUT REGISTER 

176. BR 40s 3377BRANCH TO LOAD IT 

177. 308: CALL SGTBYT 737GET NEXT BYTE FROM USER BUFFER 

178. MOVB (SP)+, (R4) 32;LOAD BYTE INTO OUTPUT REGISTER 

179. 40S: JMP SINTXT 37 EXIT FROM INTERRUPT 

180. 50S: INC U.CNT (R5) 33;RESET BYTE COUNT 

181. 608: CLR -(R4) 77 ;DISABLE PUNCH INTERRUPTS 

182. CALL SFORK 77 ;CREATE SYSTEM PROCESS 

183. MOV U.SCB(R5) ,R4 ;POINT R4 TO SCB 

184. MOV S.PKT(R4),R1 ;POINT R1 TO I/O PACKET 

185. MOV I.PRM+4(R1),R1 ; AND PICK UP CHARACTER COUNT 

186. SUB U.CNT(R5),R1 ;CALCULATE CHARACTERS TRANSFERRED 

187. MOV #IS.SUC&377,RO ;ASSUME SUCCESSFUL TRANSFER 

188. Tst U.CW3(R5) ;DEVICE ERROR? 

189, BPL 708 ;IF PL NO 

190. 65S: MOV #IE.VER&377,RO ;UNRECOVERABLE HARDWARE ERROR CODE 
191. 70S: CALL SIODON ;INITIATE 1/0 COMPLETION 

192. BR PPINI ;BRANCH BACK FOR NEXT REQUEST 

193. 

194, ; 

195. ; DEVICE TIMEOUT RESULTS IN A NOT READY MESSAGE BEING PUT our 4 TIMES A 
196. ; MINUTE. TIMEOUTS ARE CAUSED BY POWERFAILURE AND PUNCH FAULT CONDITIONS. 
197. ; 

198. 

199. PPOUT: CLRB @S.CSR(R4) 77 ;DISABLE PUNCH INTERRUPT 

200. CLRB PS 77 zALLOW INTERRUPTS 

201. $: MOV #IE.DNR&377,RO ;ASSUME DEVICE NOT READY ERROR 

202. MOV U.CW2(R5),R1 ;ARE WE WAITING FOR DEVICE READY? 

203. BPL 708 ;IF PL NO, TERMINATE I/O REQUEST 

204. MOV #IE.ABO&377,RO ;ASSUME REQUEST IS TO BE ABORTED 

205. ASL Rl ;ABORT REQUEST? 

206. BMI 70$ ;1F MI YES 

207. TST @S.CSR(R4) ; PUNCH READY? 

208. BPL 20S ;IF PL YES 

209. MOV #T.NDNR, RO ;SET FOR NOT READY MESSAGE 

210. MOVB #1,S.CTM(R4) ;SET TIMEOUT FOR 1 SECOND 

211. DECB S.STS (R4) ;TIME TO OUTPUT MESSAGE? 

212. BNE PPPWF ;IF NE NO 

213. MOVB #15.,5.STS(R4) ;SET TO OUTPUT NEXT MESSAGE IN 15. SECONDS 
214. CALLR SDVMSG ;OUTPUT MESSAGE AND RETURN 

215. »~DSABL LSB 
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216. 

217. ¢ 

218. 3; CANCEL I/O OPERATION-FORCE I/O TO COMPLETE IF DEVICE IS NOT READY 
219. ; 

220. 

221. PPCAN: CMP R1,1I.TCB(RO) 77;REQUEST FOR CURRENT TASK? 

222. BNE 10s s;771F NE NO 

223. BIS #ABORT,U.CW2(R5) 777SET FOR ABORT IF DEVICE NOT READY 
224. 1058: RETURN the 

225. 

226. - END 


6.3 HANDLING SPECIAL USER BUFFERS 


Some drivers need to handle user buffers in addition to the buffer 
that the Executive address-checks and relocates in a normal transfer 
request. Address checking and relocation operations must take place 
in the context of the task issuing the I/O request, because the 
mapping registers are set for the issuing task. However, in the 
normal driver interface, the task context after the call to SGTPKT is 
not, in general, that of the issuing task. 


Thus, drivers that need to handle special buffers must be able to 
reference the I/O packet before it is queued, while the context of the 
issuing task is still intact. 


The following coding excerpts from a standard RSX-11M driver (the 
AFC1l1l driver) illustrate the handling of a special user buffer. The 
key points are: 


@ The UC.QUE bit has been set in the control byte (U.CTL) of the 
UCB for each device/unit. (This is not shown in the coding 
excerpts below.) 


e The routine that is referenced as the initiator entry point in 
the driver dispatch table performs the following actions: 


1. Picks up the user virtual address and conditionally 
address~checks it. 


2. Relocates the virtual address, storing the result back 
into the packet. 


3. Inserts the packet into the I/0 queue and falls through 
to the entry point AFINI, which calls $GTPKT. 


e The driver propagates its own execution by branching back to 
AFINI to call S$GTPRT. 


DRIVER DISPATCH TABLE 


me Ne Ne 


SAFTBL::.WORD AFCHK ;DEVICE INITIATOR ENTRY POINT 
»-WORD AFCAN ;CANCEL I/O OPERATION ENTRY POINT 
-WORD AFOUT ;DEVICE TIMEOUT ENTRY POINT 
WORD AFPWF 7;POWERFAIL ENTRY POINT 


= 


me Ne Ne Te Se Te Ne Me NH TO Me Ne Se NO ME TO NO Se NO SNP SO me te Me 
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+ 
**-APCHK-AFC11 ANALOG TO DIGITAL CONVERTER CONTROLLER PARAMETER CHECKING 


THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 

IS RECEIVED FOR THE AFC11 ANALOG TO DIGITAL CONVERTOR. AFC11 I/O REQUESTS 
CONTAIN DEVICE DEPENDENT INFORMATION THAT MUST BE CHECKED IN THE CONTEXT 

OF THE ISSUING TASK. THEREFORE THE I/O REQUEST IS NOT QUEUED BEFORE CALLING 
THE DRIVER. 


INPUTS: 


R1=ADDRESS OF THE I/O REQUEST PACKET. 
R4=ADDRESS OF THE STATUS CONTROL BLOCK. 
RS5S=ADDRESS OF THE UCB OF THE CONTROLER TO BE INITIATED. 


OUTPUTS: 


THE CONTROL BUFFER IS ADDRESS CHECKED TO DETERMINE WHETHER IT LIES 
WITHIN THE ISSUING TASK'S ADDRESS SPACE. IF THE ADDRESS CHECK 
SUCCEEDS, THEN THE CONTROL BUFFER ADDRESS IS RELOCATED AND STORED 
IN THE I/O PACKET, THE I/O PACKET IS INSERTED IN THE CONTROLLER 
QUEUE, AND THE DEVICE INITIATOR IS ENTERED TO START THE CONTROLLER. 
ELSE AN ILLEGAL BUFFER STATUS IS RETURNED AS THE FINAL I/O STATUS 
OF THE REQUEST. 


AFCHK: MOV R1,R3 :COPY ADDRESS OF I/O PACKET 


MOV I. PRM+6(R3),RO ;GET VIRTUAL ADDRESS OF CONTROL BUFFER 


-IF DF ASSCHK!MSS$MGE 


MOV I.PRM+4(R3),R1 ;SET LENGTH OF BUFFER TO CHECK 
CALL SACHCK ;ADDRESS CHECK CONTROL BUFFER 
BCC 10$ ;IF CC ADDRESS OKAY 
MOV #IE.SPC&377,RO ;SET ILLEGAL BUFFER STATUS 
CALLR SIOFIN ;FINISH I/O OPERATION 
. ENDC 

108: CALL SRELOC ;RELOCATE CONTROL BUFFER ADDRESS 
MOV R1,1I.PRM+6(R3) ;SET RELOCATION BIAS OF CONTROL BUFFER 
MOV R2,1.PRM+10(R3) ;SET ADDRESS OF CONTROL BUFFER 
MOV R3,R1l :SET ADDRESS OF I/O PACKET 
MOV R4,R0 ;SET ADDRESS OF I/O QUEUE LISTHEAD 
CALL SQINSP ;INSERT I/O PACKET IN REQUEST QUEUE 
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+ 


**-APINI-AFC1] ANALOG TO DIGITAL CONVERTOR CONTROLLER INITIATOR 


THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 

IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECU- 
TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT 
IS MADE TO DEQUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS 
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPER- 
ATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED. 


me Me Me TO Ne Me Ne Me we 


INPUTS: 
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 
OUTPUTS: 
IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT 


ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER- 
ATION IS INITIATED. 


we SO we Te Ne Ne Ne Ne Me NO Ne 


~ENABL LSB 
AFINI: CALL $GT PKT ;GET AN I/O PACKET TO PROCESS 
BCS AFCAN 7IF CS CONTROLLER BUSY OR NO REQUEST 
71/0 CANCEL (AFCAN) IS A NO-OP FOR AFCl1l 


me te Ne 
e 


CALL SIODON sFINISH I/O OPERATION 
BR AFINI 7GO AGAIN 


me te Me 
. 


APPENDIX A 


DEVELOPMENT OCF THE ADDRESS DOUBLEWORD 


A.1 INTRODUCTION 


You can generate an RSX-11M system as a mapped or an unmapped system. 
Mapped systems can accommodate configurations whose maximum physical 
memory is 4096K bytes. Individual tasks, however, are limited to 64K 
bytes. The addressing in a mapped system uses virtual addresses and 
memory mapping hardware. I/O transfers, however, use physical 
addresses 18 bits in length. Since the PDP-11 word size is 16 bits, 
some scheme is necessary to represent an address internally until it 
is actually used in an I/0 operation. The choice was made to encode 
two words as the internal representation of a physical address, and to 
transform virtual addresses for I/0 operations into the internal 
doubleword format. 


A.2 CREATING THE ADDRESS DOUBLEWORD 


For unmapped systems, the doubleword is simply a word of zeros 
followed by a word containing the real address. 


On receipt of a QIO directive for mapped systems, the buffer address 
in the DPB, which contains a task virtual address, is converted to 
address doubleword format. 
The virtual address in the DPB is structured as follows: 

Bits 0-5 Displacement in terms of 32-word blocks 


Bits 6-12. Block number 


Bits 13.-15. Page Address Register (PAR) number 


DEVELOPMENT OF THE ADDRESS DOUBLEWORD 


The internal RSX-11M translation restructures this virtual address 
into an address doubleword as follows: 


1. 


The relocation base contained in the PAR specified by the PAR 
number in the virtual address in the DPB is added to the 
block number in the virtual address. The result becomes the 
first word of the address doubleword. It represents the nth 
32-word block in a memory viewed as a collection of 32-word 
blocks. Note that at the time the address doubleword is 
computed, the user issuing the QIO directive is mapped into 
the processor's memory management registers. 


The second word is formed by placing the 
displacement-in-block (bits 0-5 of virtual address) into bits 
0-5. The block number field was accommodated in the first 
word and bits 6-12. are cleared. Finally, a 6 is placed in 
bits 13.-15. to enable use of PAR #6, which the Executive 
uses to service I/O for program transfer devices. 


For non-processor request (NPR) devices, the driver 
requirements for manipulating the address doubleword are 
direct and are discussed with the description of U.BUF in 
Section 4.1.4.1. 


APPENDIX B 


DRIVERS FOR NPR. DEVICES USING EXTENDED MEMORY 


You must build special featurés into drivers for nonextended memory 
NPR devices attached to a PDP-1ll processor with extended-memory 
support (22-bit addressing). 


Nonextended memory NPR devices on the PDP-11 processor must perform 
I/O transfers by means of UNIBUS Mapping Registers (UMRs), as 
described in the PDP-11 Processor Handbook. One UMR is required for 
each 4K words involved in the transfer--as specified by the contents 
of U.CNT in the UCB. When multiple UMRs are required for a_ transfer, 
they must be contiguous. 


A driver can be assigned UMRs through one of three procedures. These 
procedures involve the following: 


1. Dynamically allocating UMRs for the duration of the data 
transfer 


2. Dynamically allocating UMRs for longer periods of time 


3. Statically allocating UMRs during system generation 


NOTE 


In large systems, using the second and 
third procedures above to hold UMRs for 
longer periods than necessary can result 
in the blocking of other drivers and a 
reduction in system throughput. 


B.1 CALLING S$STMAP AND SMPUBM OR SSTMP1 AND SMPUB1 


To obtain UMRs through use of the $STMAP and SMPUBM or S$STMP1 and 
SMPUB1 routines, a driver must: 


1. If it uses $STMAP and SMPUBM or S$STMP1 and S$MPUB1, allocate 
six additional words for a mapping register assignment block 
at the end of the device's SCB (at S.MPR). If it uses SSTMP1 
and S$MPUB1, also provide a 10-word block. 


2. Call the routine $STMAP or SSTMP1 (set up UNIBUS mapping 
address) after getting the I/O packet. 


3. Call the routine SMPUBM or SMPUB1 (map UNIBUS to memory) 
before initiating a transfer. 
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These requirements are detailed in the following three subsections. 


Note that these routines are only required when the driver is 
performing a data transfer. 


B.1.1 Allocating a Mapping Register Assignment Block 


The status control block (SCB) of an NPR device requires an additional 
six words. This 6-word mapping register assignment block is located 
at S.MPR, at the end of the SCB. It does not have to be initialized. 
Any initial contents are simply overwritten. 


The following example shows the allocation of a mapping register 
assignment block. The code is conditional on the result of an AND 
operation on the two symbols MSSEXT and MSSMGE (representing extended 
memory support and memory management unit support, respectively). 


-IF DF MSSEXT&MSSMGE 
. BLEW 6 ;UMR WORK AREA 
. ENDC 


If the driver does not support parallel NPR operations requiring UMR 
mapping, it calls $STMAP and S$MPUBM. If the driver supports parallel 
NPR operations requiring UMR mapping, it must call S$STMP1 and SMPUB1. 
In the latter situation, the six additional words starting at S.MPR in 
the SCB are not used but must still be present. In addition, the 
driver must provide a 10-word mapping register assignment block for 
each data transfer to be mapped, as specified in the description of 
SSTMP1 in Chapter 5. 


B.1.2 Calling S$STMAP or S$STMP1 


In the coding at the initiator entry point, after the call to $GTPKT, 
the NPR device driver must call the routine $STMAP or S$STMP1. These 
routines dynamically allocate required UMRs. If UMRs are not 
available immediately, the driver is blocked. Such blocking, if it 
occurs, is completely transparent to the driver. The driver resumes 
processing at fork level when the UMRs have been allocated. The 
register returns are absolutely identical whether or not blocking has 
occurred. 


SSTMAP or SSTMP1 stores into U.BUF and U.BUF+2 (in the UCB) a UNIBUS 
address that causes the appropriate UMR to be selected for mapping the 
transfer. The call to $STMAP or SSTMP1 must be conditional on MSSEXT 
and MSSMGE. 


Because SSTMAP and $STMP1 push the address of routine $DQUMR+2 _ onto 
the stack before returning to the caller, the driver should not use 
the stack for temporary data storage when it calls S$STMAP or $STMP1. 
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B.1.3 Calling $MPUBM or SMPUB1 


Before executing the transfer, the driver must call $MPUBM or SMPUB1. 
These routines get the buffer's 22-bit physical address, and load the 
UNIBUS mapping registers so that transfers are mapped directly to the 
task's space. The call to $MPUBM or SMPUB1 must be conditional on 
MSSEXT and MSSMGE. 


If the driver calls SSTMAP and S$MPUBM, the UMRs allocated to it are 
deallocated during the call to $IODON or S$IOALT. If the driver calls 
SSTMP1 and S$MPUB1, it must call SDEUMR to deallocate any allocated 
UMRs before calling S$IODON or SIOALT. 


B.2 CALLING SASUMR AND $DEUMR 


Some drivers may not require UMRs to be allocated all of the time, and 
yet require UMRs for periods of time longer than the normal time frame 
between SGTPKT and S$IODON (or S$IOALT). In such cases, there is a 
second procedure for allocating UMRs. 


By using the Executive routines SASUMR and S$DEUMR, a driver can 
dynamically allocate, retain over a desired time frame, and deallocate 
UMRs. Refer to Section 5.3 for a description of the S$ASUMR and $DEUMR 
routines. 


Similar to the $STMAP/SMPUBM procedure, using $ASUMR and S$DEUMR also 
requires the allocation of a 6-word mapping register assignment block. 
In this instance, however, the block must not be located at offset 
S.MPR in the SCB. SIODON or SIOALT, when called, will attempt to 
deallocate the UMRs of a block found at location S.MPR. To avoid 
this, the mapping register assignment block could, for convenience, be 
located at S.MPR+2. Alternatively, it could be dynamically allocated 
from the pool. Figure B-1 details the format of the 6-word block. 


M.LNK Link Word 

M.UMRA Address of first assigned UMR 

M.UMRN Number of assigned UMRs *4 

M.UMVL Low 16 bits mapped by first assigned UMR 
M.UMVH High 6 bits of High 2 bits mapped by 
M.BFVH physical buffer address UMR (in bits 4 and 5) 
M.BFVL Low 16 bits of physical buffer address 


2K-226-81 


Figure B-l1 Mapping Register Assignment Block 
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B.3 STATICALLY ALLOCATING UMRS DURING SYSTEM GENERATION 


You can statically assign UMRs during system generation. For systems 
with extended memory support and memory management unit support, the 
system generation procedure defines the symbol NSSUMR equal to a fixed 
number of UMRs, multiplied by 4, that are statically assigned to the 
system. Before assembling the Executive, you can cause the _ static 
allocation of an additional number of UMRs by editing file RSXMC.MAC. 
The value of the symbol NSSUMR can then be increased to represent the 
additional number of desired UMRs multiplied by 4. 


RSXMC.MAC further defines the following three symbols, which describe 
the first UMR statically allocated during system generation: 


USSMRN is the I/O page address of the first UMR register 
available for allocation to the user. 


USSMLO represents the low-order 16 bits of the 18-bit UNIBUS 
address mapped by this UMR. 


USSMHI represents the high-order two bits of the 18-bit UNIBUS 
address. These two bits are in bit positions 4 and 5. 


These three symbols are not used by the system itself. They are 
available for the user's information. 
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SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


This appendix describes the system data structures listed in Table 
c-l. 


The data structures are defined by macros in the Executive macro 
library. To reference any of the data structure offsets from your 
code, include the macro name in an .MCALL directive and invoke’ the 
macro. For example: 


-MCALL DCBDFS 
DCBDFS ;Define DCB offsets 


NOTE 


All physical offsets and bit definitions 
are subject to change in future releases 
of the operating system. Code that 
accesses system data structures should 
always use the symbolic offsets rather 
than the physical offsets. 


The first two arguments, <:> and <=>, make all definitions global. If 
they are left blank, the definitions will be local. The SYSDEF 
argument causes the variable part of a data structure to be defined. 


All of these macros are in the Executive macro library 
LB: [1, 1] EXEMC.MLB. All except ITBDFS and MTADFS are also in the 
Executive definition library LB: [{1,1]EXELIB.OLB. 
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Table C-1l 
Summary of System Data Structure Macros 


ABODFS$ <2>,<=> Task abort and termination 
notification message codes 


CLEDFS <:>,<=> Clock queue control block 

DCBDFS$ <2>,<=> Device Control Block 

EPKDFS <:>,<=> Error message block 

F11DF$ <:>,<=>,SYSDEF Files-ll data structures (volume 


control block, mount list entry, 
file control block, file window 
block, locked block list node) 


HDRDFS$ <:>,<=> Task header and window block 

HWDDFS <2>,<=> Hardware register addresses and 
feature mask definitions 

ITBDFS <:>,<=>,SYSDEF Interrupt transfer block 

LCBDFS$ <:>,<=> Logical assignment control block 

MTADFS <2>,<=> ANSI magtape data structures 


(volume set control block) 


PCBDF$ <:>,<=>,SYSDEF Partition control block and 
attachment descriptor 


PKTDFS €2>,<=> I/O packet, AST control block, 
offspring control block, group 
global event flag control block, 
and CLI parser block 

SCBDFS <:>,<=>,SYSDEF Task Control Block 


UCBDFS$ <:>,<=>, TTDEF,SYSDEF Unit Control Block 


ABODFS 


we MA Se NO Me 


§.CACT=-4. 
S.CEXT=-2. 
§.COAD=0. 

§.CSGF=2. 

S.CBPT=4. 

S.CIOT=6. 

S.CILI=8. 

S.CEMT=10. 
S.CTRP=12. 
S.CFLT=14. 
S.CSST=16. 
S.CAST=18. 
S.CABO=20. 
S.CLRF=22. 
S.CCRF=24. 
S. IOMG=26. 
S.PRTY=28. 
S.CPMD=30. 
S.CINS=32. 


me 3 te 


T.NDNR=0 
T.NDSE=2 
T.NCWF=4 
T,NCRE=6 
T.NDMO=8. 
T.NUER=10. 
T.NLDN=12. 
T.NLUP=14. 
T.NCFI=16. 
T,NUDE=18. 
T.NMPE=20. 
T,NKLF=22. 
T,NDEB=24. 
T.NRCT=26. 
T.NWBL=28. 


TASK ABORT CODES 


;TASK 
sTASK 
;TASK 
;TASK 
; TASK 
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NOTE: S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS 


;TASK STILL ACTIVE 

:TASK EXITTED NORMALLY 

:ODD ADDRESS AND TRAPS TO 4 
;SEGMENT FAULT 

;BREAK POINT OR TRACE TRAP 

;IOT INSTRUCTION 

; ILLEGAL OR RESERVED INSTRUCTION 
;NON RSX EMT INSTRUCTION 

;TRAP INSTRUCTION 


ABODFS 


311/40 FLOATING POINT EXCEPTION 


;SST ABORT-BAD STACK 

;AST ABORT-BAD STACK 

;ABORT VIA DIRECTIVE 

LOAD REQUEST FAILURE 
CHECKPOINT READ FAILURE 
EXIT WITH OUTSTANDING I/O 
MEMORY PARITY ERROR 
ABORTED WITH PMD REQUEST 
;TASK INSTALLED IN TWO SYSTEMS 


TASK TERMINATION NOTIFICATION MESSAGE CODES 


;DEVICE NOT READY 

;DEVICE SELECT ERROR 
;CHECKPOINT WRITE FAILURE 
;CARD READER HARDWARE ERROR 
;DISMOUNT COMPLETE 

; UNREC OVERABLE ERROR 

sLINK DOWN (NETWORKS) 

:LINK UP (NETWORKS ) 
;CHECKPOINT FILE INACTIVE 
;UNREC OVERABLE DEVICE ERROR 
;MEMORY PARITY ERROR 

;UCODE LOADER NOT INSTALLED 
TASK HAS NO DEBUGGING AID 
;REPLACEMENT CONTROL TASK NOT INSTALLED 
:;WRITE BACK CACHING DATA LOST 
;UNIT WRITE LOCKED 
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CLKDF$ 


000000 
000002 
000003 
000004 
000006 


000012 
000014 
000016 


000012 
000016 


000012 
000016 


CLKDFS 


CLOCK QUEUE CONTROL BLOCK OFFSET DEFINITIONS 
CLOCK QUEUE CONTROL BLOCK 


THERE ARE SIX TYPES OF CLOCK QUEUE CONTROL BLOCKS. EACH CONTROL 
BLOCK HAS THE SAME FORMAT IN THE FIRST FIVE WORDS AND DIFFERS IN 
THE REMAINING THREE, 


THE FOLLOWING CONTROL BLOCK TYPES ARE DEFINED: 


-MRKT=0 ;MARK TIME REQUEST 

- SCHD=2 #TASK REQUEST WITH PERIODIC RESCHEDULING 

. SSHT=4 ;SINGLE SHOT TASK REQUEST 

- SYST=6 ;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (IDENT) 
- SYTK=8. #SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (TASK) 
-CSTP=10. 7CLEAR STOP BIT (CONDITIONALIZED ON SHUFFLING) 


T1 OO OVO Ose se ne Se ee Ne we Se we Ne we 


CLOCK QUEUE CONTROL BLOCK TYPE INDEPENDENT OFFSET DEFINITIONS 


Se Ne Ne 


-ASECT 
-=0 
C.LNK: .BLKW 
C.ROT: .BLKB 
C.EFN: .BLKB 
C.TCB: .BLKW 
C.TIM: .BLKW 


;CLOCK QUEUE THREAD WORD 
;REQUEST TYPE 

;EVENT FLAG NUMBER (MARK TIME ONLY) 

7TCB ADDR OR SYSTEM SUBROUTINE IDENTIFICATION 
sABSOLUTE TIME WHEN REQUEST COMES DUE 


NRE Rew 


CLOCK QUEUE CONTROL BLOCK-MARK TIME DEPENDENT OFFSET DEFINITIONS 


=C.TIM+4 7;START OF DEPENDENT AREA 

-AST: .BLKW ;AST ADDRESS 

-SRC: .BLKW 7FLAG MASK WORD FOR 'BIS' SOURCE 
-DST:  .BLKW ;ADDRESS OF 'BIS' DESTINATION 


AAA: wa rewe 
BRE 


CLOCK QUEUE CONTROL BLOCK-PERIODIC RESCHEDULING DEPENDENT OFFSET 
DEFINITIONS 


ee Ne Me Ne 


=C.TIM+4 ;START OF DEPENDENT AREA 
C.RSI: ,BLKW *RESCHEDULE INTERVAL IN CLOCK TICKS 
C.UIC: .BLKW *SCHEDULING UIC 


eh 


7; CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT DEPENDENT OFFSET DEFINITIONS 


=C.TIM+4 ;START OF DEPENDENT AREA 
- BLKwW 2 ;TWO UNUSED WORDS 
- BLKW 1 ;SCHEDULING UIC 


000012 
000014 
000016 


000020 
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DEFINITIONS 


CD OC) we me te ue te No me Ne me me Ne we 


TYPE 6 
TYPE 8 
=C.TIM+4 
-SUB: .BLKW 
-AR5: .BLKW 
- BLKW 
C.LGTH=. 
-PSECT 


CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET 


THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST: 


SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE 


AS AN IDENTIFIER. 


— 


SINGLE SHOT INTERNAL SUBROUTINE WITH A TCB ADDRESS 
AS AN IDENTIFIER. 


;START OF DEPENDENT AREA 
;SUBROUTINE ADDRESS 

;RELOCATION BASE (FOR LOADABLE DRIVERS) 
ONE UNUSED WORD 


;LENGTH OF CLOCK QUEUE CONTROL BLOCK 
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DCBDF$ 


000000 
000002 
000004 
000006 
000007 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 


DCBDFS$ 


DEVICE CONTROL BLOCK 


THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT 
A DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS, THERE IS 
AT LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM. FOR EXAMPLE, 
IF THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE 
DCB WITH THE DEVICE NAME 'TT'. IF PART OF THE TELETYPES WERE 
INTERFACED VIA DL11-A'S AND THE REST VIA A DH11, THEN THERE 
WOULD BE TWO DCB'S. ONE FOR ALL DL11-A INTERFACED TELETYPES, 

AND ONE FOR ALL DH11 INTERFACED TELETYPES. 


me te Se Me we Ne tH Ne tO Ne Ne Ne 


-ASECT 
-=0 
D.LNK: .BLKW 1 ;LINK TO NEXT DCB 
D.UCB: .BLKW 1 ;POINTER TO FIRST UNIT CONTROL BLOCK 
D.NAM: .BLKW 1 ;GENERIC DEVICE NAME 
D.UNIT: .BLKB Al ;LOWEST UNIT NUMBER COVERED BY THIS DCB 
- BLKB 1 ;HIGHEST UNIT NUMBER COVERED BY THIS DCB 
D.UCBL: .BLKW 1 ;LENGTH OF EACH UNIT CONTROL BLOCK IN BYTES 
D.DSP: .BLKW 1 ;POINTER TO DRIVER DISPATCH TABLE 
D.MSK: .BLKW 1 ;LEGAL FUNCTION MASK . CODES 0-15. 
- BLKW A; ;CONTROL FUNCTION MASK CODES 0-15. 
- BLEW 1 ;NOP'ED FUNCTION MASK CODES 0-15. 
-BLKW 1 ;ACP FUNCTION MASK CODES 0-15. 
-BLKW 1 ;LEGAL FUNCTION MASK CODES 16.-31. 
- BLKW 1 ;CONTROL FUNCTION MASK CODES 16.-31. 
-BLKW 1 zNOP'ED FUNCTION MASK CODES 16.-31. 
- BLKW 1 ;ACP FUNCTION MASK CODES 16.-31. 
D.PCB: .BLKW 1 ;LOADABLE DRIVER PCB ADDRESS 
- PSECT 


DRIVER DISPATCH TABLE OFFSET DEFINITIONS 


me te Ne 


D. VDEB=177776 ;DEALLOCATE INTERNAL BUFFERS (FD TTDRV) 


D. VINI=0 ;DEVICE INITIATOR 

D. VCAN=2 ;CANCEL CURRENT I/O FUNCTION 
D. VOUT =4 ;DEVICE TIMEOUT 

D. VPWF=6 ; POWERFAIL RECOVERY 


000000 
000002 
000004 
000005 
000006 
000012 
000013 
000014 
000016 
000020 
000020 
000021 
000022 
000030 
000031 
000032 


000034 
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EPKDF$ 

EPKDFS 
7 
; ERROR MESSAGE BLOCK DEFINITIONS 
a’ 

~ASECT 
; HEADER SUBPACKET 
: 
; 
; a a a a a na a a + 
; | SUBPACKET LENGTH IN BYTES | 
? Pes Se a Se SSeS rs SSS ster Sessa Ssece + 
: | SUBPACKET FLAGS | 
; ta = SSS SSS tS Ss 5- 5-52 5>—-—-S555= + 
: | FORMAT IDENTIFICATION | OPERATING SYSTEM CODE | 
: tes-S-s-S S55 hese SS3$5S-F55--S5S57F> + 
; | OPERATING SYSTEM IDENTIFICATION | 
i | | 
H tere nnn eS SSS SSS ea SSS SSS Sr SSS + 
H | FLAGS | CONTEXT CODE | 
: 4+----------------------- +-------------------~---- + 
; | ENTRY SEQUENCE | 
; eae S Se sete SS Ss SS Sa SS SSS SSS SSS SSS S5Ss555= + 
; | ERROR SEQUENCE | 
; SeSSsesre SSS sass PeSa sess eas — + 
: | ENTRY TYPE SUBCODE | ENTRY TYPE CODE | 
? tere rrr nr rrr P= ==S$S5- SSS <3 54S55-— > + 
; | TIME STAMP | 
i | | 
i | | 
; SS 7S=sS-S5S95-S5-S45-4- tees Se Sao S SSeS SS + 
; | RESERVED | PROCESSOR TYPE | 
; to SSe-S SSS HS 5a a ar mc eet + 
; | PROCESSOR IDENTIFICATION (URM) | 
H i chai a al aa aaa a ca a cat te ae a + 
7 
-=0 
ESHLGH: .BLKW 1 3; SUBPACKET LENGTH IN BYTES 
ESHSBF: .BLKW 1 7 SUBPACKET FLAGS 
ESHSYS: .BLKB 1 3; OPERATING SYSTEM CODE 
ESHIDN: .BLKB 1 ; FORMAT IDENTIFICATION 
ESHSID: .BLKB 4 ; OPERATING SYSTEM IDENTIFICATION 
ESHCTX: .BLKB 1 3; CONTEXT CODE 
ESHFLG: .BLKB 1 ; FLAGS 
ESHENS: .BLKW i 3; ENTRY SEQUENCE NUMBER 
ESHERS: .BLKW 1 ; ERROR SEQUENCE NUMBER 
ESHENC: 7 ENTRY CODE 
ESHTYC: .BLKB 1 ; ENTRY TYPE CODE 
ESHTYS: .BLKB 1 ; ENTRY TYPE SUBCODE 
ESHTIM: .BLKB 6 ; TIME STAMP 
ESHPTY: .BLKB 1 3 PROCESSOR TYPE 

. BLKB 1 3; RESERVED 
ESHURM: .BLKW 1 ; PROCESSOR IDENTIFICATION (URM) 

- EVEN 
ESHLEN: ; LENGTH 


me Ne te 


me Ne Ne 


me Me Ne 


me Ne Me Ne te Ne 
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SUBPACKET FLAGS 


SM. ERR 
SM.HDR 
SM.TSK 
SM.DID 
SM.DOP 
SM.DAC 
SM.DAT 
SM.MBC 
SM.CMD 
SM.ZER 


CODES FOR FIELD ESHIDN 


EHSFOR 


FLAGS FOR THE 


ES.INI 
ES.DAT 
ES.LIM 
ES.LOG 


1; 


ERROR LOG 


“onion a 
OPN E 


we Ne we we 


FOR ESHSBF 
= 1 ; ERROR PACKET 
= 1 ; HEADER SUBPACKET 
= 2 ; TASK SUBPACKET 
= 4 ; DEVICE IDENTIFICATION SUBPACKET 
= 10 ; DEVICE OPERATION SUBPACKET 
= 20 ; DEVICE ACTIVITY SUBPACKET 
= 40 ; DATA SUBPACKET 
= 20000 ; 22-BIT MASSBUS CONTROLLER PRESENT 
= 40000 ; ERROR LOG COMMAND PACKET 
=100000 ; ZERO I/O COUNTS 


CURRENT PACKET FORMAT 


FLAGS BYTE (SERFLA) IN THE EXEC 


ERROR LOG INITIALIZED 
ERROR LOG RECEIVING DATA PACKETS 
ERROR LIMITING ENABLED 
ERROR LOGGING ENABLED 


TYPE AND SUBTYPE CODES FOR FIELDS ESHTYC AND ESHTYS 


SYMBOLS 
SYMBOLS 


ESCCMD 
ESSSTA 
ESSSWI 
ESSAPP 
ESSBAC 
ESSSHO 
ESSCHL 


ESCERR 
ESS DVH 
ESSDVS 
ESSTMO 
ESS UNS 


ESCDVI 
ESSDVI 


ESCDCI 
ESSMOU 
ESS DMO 
ESSRES 
ESSRCT 


ESCCPU 
ESSMEM 
ESSINT 


ESCSYS 
ESS PWR 


WITH NAMES ESCXXX ARE TYPE CODES FOR FIELD ESHTYC, 
WITH NAMES ESSXXX ARE SUBTYPE CODES FOR FIELD ESHTYS. 


DU &WNHR FH 
=e =F Se Se Ne NO NO 


Hoi wud 
m WN EF ND 
mee te we Ne 


tou 
rw 


to wow a ou 
Bm WN 
me ™e me Ge NO me Ne 


ou a 


RO NRW 
sete we 


ue Me 


ERROR LOG CONTROL 
ERROR LOG STATUS CHANGE 
SWITCH LOGGING FILES 
APPEND FILE 
DECLARE BACKUP FILE 
SHOW 
CHANGE LIMITS 


DEVICE ERRORS 
DEVICE HARD ERROR 
DEVICE SOFT ERROR 
DEVICE INTERRUPT TIMEOUT 
DEVICE UNSOLICITED INTERRUPT 


DEVICE INFORMATION 
DEVICE INFORMATION MESSAGE 


DEVICE CONTROL INFORMATION 
DEVICE MOUNT 
DEVICE DISMOUNT 
DEVICE COUNT RESET 
BLOCK REPLACEMENT 


CPU DETECTED ERRORS 
MEMORY ERROR 
UNEXPECTED INTERRUPT 


SYSTEM CONTROL INFORMATION 
POWER RECOVERY 


000000 
000002 
000006 
000010 
000012 
000013 


000014 


CODES 


ue ee Ne 


CODES 


me Me me 


we ee we Se Se ee Ne te me Me te Ne te Ne 


- =0 

ESTLGH: 
ESTTSK: 
ESTUIC: 
ESTTID: 
ESTTIU: 
ESTFLG: 


ESTLEN: 


FLAGS 


me te Ne 
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ESCCTL 
ESSTIM 
ESSCRS 
ESS LOA 
ESSUNL 
ESSHRC 
ESSMES 


win wut doa 


ESCSDE 
ESSABO 


AM PWNE s] 
me “Oe Se ME ue we TO 


tw 
we Me 


CONTROL INFORMATION 
TIME CHANGE 
SYSTEM CRASH 
DEVICE DRIVER LOAD 
DEVICE DRIVER UNLOAD 
RECONFIGURATION STATUS CHANGE 
MESSAGE 


SOFTWARE DETECTED EVENTS 
TASK ABORT 


FOR CONTEXT CODE ENTRY ESHCTX 


TASK SUBPACKET 


EHSNOR = 1 ; NORMAL ENTRY 

EHSSTA = 2 ; START ENTRY 

EHSCRS = 3 ; CRASH ENTRY 

FOR FLAGS ENTRY ESHFLG 

EHSVIR = 1 ; ADDRESSES ARE VIRTUAL 

EHSEXT = 2 ; ADDRESSES ARE EXTENDED 

EHSCOU = 4 ; ERROR COUNTS SUPPLIED 
4$------------------------ = +--+ ----- == --- === ---- + 
| TASK SUBPACKET LENGTH | 
4$------------------------------------ = - == === + 


$----------------------------------------------- + 
| TASK UIC | 
4$—--------~--~-------------- --- -- - --- -- - + 
| TASK TI: DEVICE NAME | 
$--------------- +--+ == $-------------- ----- == + 
| FLAGS | TASK TI: UNIT NUMBER | 
4$----------------------- 4+----------------------- + 
BLEW 1 ; TASK SUBPACKET LENGTH 

~BLKW 2 ; TASK NAME IN RADSO 

-BLKW 1 ; TASK UIC 

-BLKB 2 ; TASK TI: DEVICE NAME 

.BLKB 1 ; TASK TI: UNIT 

-BLKB 1 ; FLAGS 

. EVEN 

FOR ENTRY ESTFLG 

ETSPRV = 1 ; TASK IS PRIVILEGED 

ETSPRI = 2 ; TERMINAL IS PRIVILEGED 
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DEVICE IDENTIFICATION SUBPACKET 


i 

; 

: ran + 
. | DEVICE IDENTIFICATION SUBPACKET LENGTH | 
; ne em + 
; j DEVICE MNEMONIC NAME I 
7 ta rrr here nnn + 
; | CONTROLLER NUMBER | DEVICE UNIT NUMBER 

; Sa naan naan eee eran ec al aa cla di a + 
. | PHYSICAL SUBUNIT # | PHYSICAL UNIT # | 
; $a rrr rrr a i a a aa rater + 
; | PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
; 4f-------- + -------------- 4$----------------------- + 
; | RESERVED | FLAGS | 
; har ra tan re + 
; | VOLUME NAME OF MOUNTED VOLUME | 
i | | 
; | | 
; | | 
i | | 
; | | 
H Ge + 
: | PACK IDENTIFICATION | 
? | | 
; ee ae ae + 
; | DEVICE TYPE CLASS | 
; a a a a ee a re a SSS ae SSS 9 SSS + 
: ] DEVICE TYPE | 
; ] | 
; $32 Se a a as re sara ST ra atS + 
7 | I/O OPERATION COUNT LONGWORD 

; | I 
; Sl i a +S SS See SS oe sre + 
; | HARD ERROR COUNT | SOFT ERROR COUNT | 
; 4$----------------------- $o-------------------- ++ + 
H | BLOCKS TRANSFERRED COUNT (RSX-11M-PLUS ONLY) | 
; | | 
i 4f----------------------- += === = - += -- == -- + 
: | CYLINDERS CROSSED COUNT (RSX-11M-PLUS ONLY) | 
; | | 
; Piscean SSS aS SSS Sess Sr Sr Ss SSS SCS SSS HSS SSS + 
; 


- =0 
000000 ESILGH: .BLKW 
000002 ESILDV: .BLKW 
000004 ESILUN: .BLKB 
000005 ESIPCO: .BLKB 
000006 ESIPUN: .BLKB 
000007 ESIPSU: .BLKB 


DEVICE IDENTIFICATION SUBPACKET LENGTH 
DEVICE MNEMONIC NAME 

DEVICE UNIT NUMBER 

CONTROLLER NUMBER 

PHYSICAL UNIT NUMBER 

PHYSICAL SUBUNIT NUMBER 


PHP HHH 
me “eo Ne Ne BE Me 


~IF DF RSSMPL 


ESIPDV: .BLKW 1 PHYSICAL DEVICE MNEMONIC 


~e 


~ENDC ; RSSMPL 


000010 
000011 
000012 
000026 
000032 
000032 
000034 
000040 
000044 
000045 


000046 


000000 
000002 
000006 
000010 
000012 
000013 
000014 
000016 
000017 


ESIFLG: 


ESIVOL: 
ESI PAK: 
ESIDEV: 
ESIDCL: 
ESIDTY: 
ESIOPR: 
ESIERS: 
ESIERH: 


ESIBLK: 


ESICYL: 


ESILEN: 


FLAGS 


we Ne me 


ma Ne ee we Se Ne we Ne me MO Ne Ne Ne Se me te Ne NO Oe Ne NE Se Ne we Ne Me 


-=0 

ESOLGN: 
ESOTSK: 
ESOUIC: 
ESOTID: 


ome ee 


ESOFNC: 
ESOFLG: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- BLKB 
- BLKB 
» BLKB 
-BLKB 


- BLKW 
-BLKW 
-BLKW 
- BLKB 
- BLKB 


-IF DF RSSMPL 


- BLKW 
-BLRW 


.ENDC ; 


- EVEN 


FOR FIELD ESIFLG 


EISSUB 


PRPNNe 


2 
2 


RSSMPL 


Ct i al iT Ty 


0 Ne 


= 


. 
, 


FLAGS 

RESERVED 

VOLUME NAME 

PACK IDENTIFICATION 

DEVICE TYPE 

DEVICE TYPE CLASS 

DEVICE TYPE 

I/O OPERATION COUNT LONGWORD 
SOFT ERROR COUNT 

HARD ERROR COUNT 


BLOCKS TRANSFERRED COUNT 


CYLINDERS CROSSED COUNT 


SUBPACKET LENGTH 


SUBCONTROLLER DEVICE 


DEVICE OPERATION SUBPACKET 


4-------------------- +--+ ----- ------- -- + --- === + 
| TASK UIC | 
ton ne rr nn ee = + 
| TASK TI: LOGICAL DEVICE MNEMONIC | 
4+--~---------~---------- 4+--+--------------------- + 
| RESERVED | TASK TI: DEVICE UNIT | 
4+----------------------- 4+----------------------- + 
| I/O FUNCTION CODE | 
4+----------------------- 4+-----~~----------------- + 
| RESERVED | OPERATION FLAGS | 


$----------------------- 4----------------+ +--+ + 
| TRANSFER OPERATION ADDRESS | 


4+------------------~------------ -- ---------+----- + 
| TRANSFER OPERATION BYTE COUNT | 

4-~---------------------------- ~~ +--+ +--+ + 

| CURRENT OPERATION RETRY COUNT | 

4------------------------- = +++ ++ + 

. BLKW 1 7 SUBPACKET LENGTH 

. BLKW 2 ; TASK NAME IN RAD50 

~BLKW 1 7; TASK UIC 

. BLKB 2 3; TASK TI: LOGICAL DEVICE MNEMONIC 
- BLKB i } TASK TI: LOGICAL DEVICE UNIT 

- BLKB 1 ; RESERVED 

. BLKW 1 3; I/O FUNCTION CODE 

- BLKB 1 ; OPERATION FLAGS 

- BLKB 1 ; RESERVED 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


000020 ESOADD: .BLKW 2 ; TRANSFER OPERATION ADDRESS 
000024 ESOSIZ: .BLKW i ; TRANSFER OPERATION BYTE COUNT 
000026 ESORTY: .BLKW 1 7 CURRENT OPERATION RETRY COUNT 
. EVEN 
000030 ESOLEN: ; DEVICE OPERATION SUBPACKET LENGTH 


FLAGS FOR FIELD ESOFLG 


ea Te te 


EOSTRA = 1 ; TRANSFER OPERATION 
EOSDMA = 2 ; DMA DEVICE 
EOSEXT = 4 ; EXTENDED ADDRESSING DEVICE 
EOSPIP = 10 ; DEVICE IS POSITIONING 
; 
3 I/O ACTIVITY SUBPACKET 
? 
; $oS Ss SS SHS Serre a a es a re tS SS == + 
; |] I/O ACTIVITY SUBPACKET LENGTH | 
. a rr errr rrr + 
7 
000000 ESALGH: .BLKW i 3} SUBPACKET LENGTH 


I/O ACTIVITY SUBPACKET ENTRY 


tee iconic 4 
| COnIRCLLER NUMEERS. Ph LOCEGAL DEVICE GE | 
i SBHee Ten SURUNIE 3) GAVSTCAE NEE WEE 
7 DRYSTCAIO DEVICE NNEHONTO (RSHCVINGPRUS ONE). 1 
Puen LO oGiemE Neri BEyicnienace S| i 
4------------ --- 4+---------~-------------- + 


| REQUESTING TASK NAME IN RAD5O | 


$---------------- +--+ --+-- --------- -- ------------ + 
| REQUESTING TASK UIC | 
4$----------~~------------~----- + --- +--+ + 
| TASK TI: LOGICAL DEVICE NAME | 
4$------+--------+-------- --------- ---- = +--+ ----- + 
| I/O FUNCTION CODE | 
4$----------------------- $----------------------- + 
| RESERVED | FLAGS | 
$----------------------- $o---------------------- + 


| TRANSFER OPERATION ADDRESS | 
I | 


| TRANSFER OPERATION BYTE COUNT | 


me Ne Me a He te Ne te Ne Ne MO te me Ne TO NE Ne 8 Ne 8 Ne Ne We Pe Ne te Se Ne Be te 


000000 
000002 
000003 
000004 
000005 


000006 
000007 
000010 
000014 
000016 
000020 
000022 
000023 
000024 
000030 


000032 


-=0 

ESALDV: 
ESALUN: 
ESAPCO: 
ESAPUN: 
ESAPSU: 


ESAPDV: 


ESADFG: 
ESATIU: 
ESATSK: 
ESAUIC: 
ESATID: 
ESAFNC: 
ESAFLG: 


ESAADD: 
ESASIZ: 


ESALEN: 


FLAGS 


me SO Ne 


FLAGS 


se te Ne 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- BLKW 
- BLKB 
-BLKB 
- BLKB 
-BLKB 


BPPRPPPY 


~IF DF RSSMPL 


- BLKW 1 


~ENDC ; RSSMPL 


- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
. BLKW 
- BLKB 
- BLKB 
~ BLEW 
~BLKwW 
. EVEN 


BPP RPE RP HNE PE 


FOR FIELD 


EASSUB = 


FOR FIELD ESAFLG 


EASTRA 
EASDMA 
EASEXT 
EASPIP 


- PSECT 


ESADFG 


Ag 


OF NE 


me Ne Se we Ne 


™e 


me Se Ne Ne Ne Ne Ne Me Ne Ne 


se 


. 
f 


me me te we 


LOGICAL DEVICE NAME MNEMONIC 
LOGICAL DEVICE UNIT 
CONTROLLER NUMBER 

PHYSICAL UNIT NUMBER 
PHYSICAL SUBUNIT NUMBER 


PHYSICAL DEVICE MNEMONIC 


DEVICE FLAGS 

TASK TI: LOGICAL UNIT 
REQUESTING TASK NAME IN RADSO 
REQUESTING TASK UIC 

TASK TI: LOGICAL DEVICE NAME 
I/O FUNCTION CODE 

FLAGS 

RESERVED 

TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 


SUBPACKET ENTRY LENGTH 


SUBCONTROLLER DEVICE 


TRANSFER OPERATION 

DMA DEVICE 

DEVICE HAS EXTENDED ADDRESSING 
DEVICE IS POSITIONING 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


F11DF$ 


F1l1DFS ,,SYSDEF 


VOLUME CONTROL BLOCK 


me te Ne 


- ASECT 
- =0 


000000 V.TRCT: .~BLKW 1 TRANSACTION COUNT 


™e 


-IF DF RS$$11M 


000002 V.TYPE: .BLKB 1 VOLUME TYPE DESCRIPTOR 


000004 V.LABL: .BLKB 14 
000020 V.PKSR: .BLKW 2 


VOLUME LABEL (ASCIT) 
PACK SERIAL NUMBER FOR ERROR LOGGING 


, 
vVT.SL1= 1 ; FILES-11 STRUCTURE LEVEL 1 
VT.ANS= 10 ; ANSI LABELED TAPE 
VT.UNL= 11 ; UNLABELED TAPE 
000003 V.VCHA: .BLKB 1 ; VOLUME CHARACTERISTICS 
ve.SLK= 1 ; CLEAR VOLUME VALID ON DISMOUNT 
vC.HLK= 2 ; UNLOAD THE VOLUME ON DISMOUNT 
vVC.DEA= 4 ; DEALLOCATE THE VOLUME ON DISMOUNT 
vc. PUB= 10 ; SET (CLEAR) US.PUB ON DISMOUNT 
a 
, 


000024 V.SLEN: 


~e 


LENGTH OF SHORT VCB 
~ENDC ;RS$$11M 


000024 V.IFWI: .BLKW 1 INDEX FILE WINDOW 


oT 


-IF DF RS$11D 


V.STD: .BLKW 1 STD OF TASK CHARGED WITH NODE 


= 


~ENDC ;RS$$11D 


000026 V.FCB: .BLKW 2 ; FILE CONTROL BLOCK LIST HEAD 

000032 V.IBLB: .BLKB 1 ; INDEX BIT MAP 1ST LBN HIGH BYTE 

000033 V.IBSZ: .BLKB 1 ; INDEX BIT MAP SIZE IN BLOCKS 

000034 - BLKW 1 ; INDEX BITMAP 1ST LBN LOW BITS 

000036 V.FMAX: .BLKW 1 : MAX NO. OF FILES ON VOLUME 

000040 V.WISZ: .BLKB 1 ; DEFAULT SIZE OF WINDOW IN RTRV PTRS 
; VALUE IS < 128. 

000041 V.SBCL: .BLKB 1 ; STORAGE BIT MAP CLUSTER FACTOR 

000042 V.SBSZ: .BLKW 1 ; STORAGE BIT MAP SIZE IN BLOCKS 

000044 V.SBLB: .BLKB 1 ; STORAGE BIT MAP 1ST LBN HIGH BYTE 

000045 V.FIEX: .BLKB 1 ; DEFAULT FILE EXTEND SIZE 

000046 » BLKW 1 ; STORAGE BIT MAP 1ST LBN LOW BITS 


.IF DF RS$S11M 


VOLUME OWNER'S UIC 
VOLUME PROTECTION 


000050 V.VOWN: .BLKW 1 
000052 V.VPRO: .BLKW 1 


sete 


»ENDC ;RS$11M 


000054 V.FPRO: .BLKW 
000056 V.FRBK: .BLKB 


i VOLUME DEFAULT FILE PROTECTION 
1 
000057 V.LRUC: .BLKB 1 
1 
1 


NUMBER OF FREE BLOCKS ON VOLUME HIGH BYTE 
COUNT OF AVAILABLE LRU SLOTS IN FCB LIST 


me we te Ne Ne Ne Ne 


000060 » BLKW NUMBER OF FREE BLOCKS ON VOLUME LOW BITS 
000062 \V.STS: .BLKB VOLUME STATUS BYTE, CONTAINING THE FOLLOWING 
VS.IFW= 1 INDEX FILE IS WRITE ACCESSED 
VS.BMW= 2 STORAGE BITMAP FILE IS WRITE ACCESSED 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 
000063 V.FFNU: .BLKB 1 ; FIRST FREE INDEX FILE BITMAP BLOCK 
000064 V.EXT: .BLKW 1 ; POINTER TO VCB EXTENSION 
000066 V.LGTH: ; SIZE IN BYTES OF VCB 
; 
; MOUNT LIST ENTRY 
; 
; EACH ENTRY ALLOWS ACCESS TO A SPECIFIED USER FOR A NON-PUBLIC DEVICE 
; 
; TO ALLOW EXPANSION, ONLY THE ONLY TYPE CODE DEFINED IS "1" FOR 
; DEVICE ACCESS BLOCKS 
i 
.ASECT 
.=0 
000000 M.LNK: .BLKW 1 3; LINK WORD 
000002 M.TYPE: .BLKB 1 ; TYPE OF ENTRY 
MT.MLS= 1 ; MOUNTED VOLUME USER ACCESS LIST 
ococo3 M.ACC: .BLKB 1 ; NUMBER OF ACCESSES 
000004 M.DEV: .BLKW 1 3} DEVICE UCB 
000006 M.TI: . BLKW 1 ; ACCESSOR TI: UCB 
000010 M.LEN: ; LENGTH OF ENTRY 
7 
; FILE CONTROL BLOCK 
; 
.ASECT 
-=0 
000000 F.LINK: .BLKW 1 ; FCB CHAIN POINTER 
.IF DF R$$11D 
F.FEXT: .BLKW 1 ; POINTER TO EXTENSION FCB 
F.STD: .BLKW 1 ; STD OF TASK CHARGED WITH NODE 
~ENDC ;RS$11D 
000002 F.FNUM: .BLKW 1 3; FILE NUMBER 
000004 F.FSEQ: .BLKW 1 ; FILE SEQUENCE NUMBER 
000006 . BLKB 1 ; NOT USED 
000007 F.FSON: .BLKB 1 ; FILE SEGMENT NUMBER 
000010 F.FOWN: .BLKW 1 3; FILE OWNER'S UIC 
000012 F.FPRO: .BLKW 1. ; FILE PROTECTION CODE 
000014 F.UCHA: .BLKB 1 ; USER CONTROLLED CHARACTERISTICS 
000015 F.SCHA: .BLKB 1 ; SYSTEM CONTROLLED CHARACTERISTICS 
000016 F.HDLB: .BLKW 2 ; FILE HEADER LOGICAL BLOCK NUMBER 
; BEGINNING OF STATISTICS BLOCK 
000022 F.LBN: .BLKW 2 : LBN OF VIRTUAL BLOCK 1 IF CONTIGUOUS 
; O IF NON CONTIGUOUS 
000026 F.SIZE: .BLKW 2 ; SIZE OF FILE IN BLOCKS 
000032 F.NACS: .BLKB 1 : NO. OF ACCESSES 
000033 F.NLCK: .BLKB 1 + NO. OF LOCKS 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


000012 S.STBK=.-F.LBN SIZE OF STATISTICS BLOCK 


= 


000034 F.STAT: 
000034 F.NWAC: .BLKB 1 
000035 - BLKB 1 
FC.WAC= 100000 
FC.DIR= 40000 
FC.CEF= 20000 
FC. FCO= 10000 
000036 F,.DREF: .BLKW 1 
000040 F.DRNM: .BLKW 1 


FCB STATUS WORD 

NUMBER OF WRITE ACCESSORS 

STATUS BITS FOR FCB CONSISTING OF 

SET IF FILE ACCESSED FOR WRITE 

SET IF FCB IS IN DIRECTORY LRU 

SET IF DIRECTORY EOF NEEDS UPDATING 
SET IF TRYING TO FORCE DIRECTORY CONTIG 
DIRECTORY EOF BLOCK NUMBER 

1ST WORD OF DIRECTORY NAME 


me me 8 ee Se Ne me Ne 


-IF DF RSS11M 


000042 F.FEXT: .BLKW 1 POINTER TO EXTENSION FCB 


~ 


~ENDC ;RSS11M 


000044 F.FVBN: .BLKW 2 
000050 F.LKL: .BLKW 1 
000052 F.WIN: .BLKW 1 


STARTING VBN OF THIS FILE SEGMENT 
POINTER TO LOCKED BLOCK LIST FOR FILE 
WINDOW BLOCK LIST FOR THIS FILE 


me Ne te 


000054 F.LGTH: SIZE IN BYTES OF FCB 


we 


WINDOW 


me Me we 


-ASECT 
-=0 

000000 W.ACT: NUMBER OF ACTIVE MAPPING POINTERS 
WHEN NO SECONDARY POOL 
BLOCK SIZE OF SECONDARY POOL SEGMENT 
WHEN SECONDARY POOL 
LOW BYTE = # OF MAP ENTRIES ACTIVE 
HIGH BYTE CONSISTS OF CONTROL BITS 
READ VIRTUAL BLOCK ALLOWED IF SET 
WRITE VIRTUAL BLOCK ALLOWED IF SET 
EXTEND ALLOWED IF SET 
SET IF LOCKED AGAINST SHARED ACCESS 
SET IF DEACCESS LOCK ENABLED 


000000 W.BLKS: 
000000 W.CTL: .BLKW 1 


WI.RDV= 400 

WI.WRV= 1000 
WI.EXT= 2000 
WI.LCK= 4000 
WI.DLK= 10000 


me Ne Me Ne Se me me Ne Ne NO te 


-IF DF RS$11M 


WI.PND= 20000 WINDOW TURN PENDING BIT 


= 


-ENDC ;RS$$11M 


WI.EXL= 40000 
WI.WCK= 100000 


SET IF MANUAL UNLOCK DESIRED 
DATA CHECK ALL WRITES TO FILE 


=e owe 


-IF NDF RS$$11M 


= 


IF NOT RSX-11 


W.FCB: .BLKW 
W.STD: .BLKW 
W.VBN: .BLKB 
W.WISZ: .BLKB 
-BLKW 
W.LKL: .BLKW 
W.WIN: .BLKW 
W.RTRV: 


FILE CONTROL BLOCK ADDRESS 

STD OF TASK CHARGED WITH WIDOW NODE 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

POINTER TO LIST OF USERS LOCKED BLOCKS 
WINDOW BLOCK LIST LINK WORD 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


Meee pe 


we Ne Ne Ne Ne Ne Ne Ne 


000002 
000003 
000004 
000006 
000010 


000012 
000013 
000013 
000014 
000016 


000000 
000002 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


~IFF 
W.I0C: .BLKB 

-BLKB 
W.FCB: .BLKW 
W.LKL: .BLKW 
W.WIN: .BLKW 

-IF NB 


.IF NDF PSSWND 


we Se Me te te 


HHH E 


SYS DEF 


me Se Ne me te 


IF RSX-11 


COUNT OF I/O THROUGH THIS WINDOW 
RESERVED 

FILE CONTROL BLOCK ADDRESS 

POINTER TO LIST OF USERS LOCKED BLOCKS 
WINDOW BLOCK LIST LINK WORD 


IF SYSDEF SPECIFIED IN CALL 


IF SECONDARY POOL WINDOWS NOT ALLOWED 


NON-SECONDARY POOL WINDOW BLOCK 
IF SECONDARY POOL WINDOWS ARE NOT ENABLED, THE WINDOW BLOCK 
CONTAINS THE CONTROL INFORMATION AND RETRIEVAL POINTERS. 


W.VBN: .BLKB a ; HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

W.MAP: ; DEFINE LABEL WITH ODD ADDR TO CATCH BAD REFS 

W.WISZ: .BLKB 1 ; SIZE IN RTRV PTRS OF WINDOW (7 BITS) 
. BLKW 1 ; LOW ORDER WORD OF 1ST VBN MAPPED 

W.RTRV: ; OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 
-IFF 3; IF WINDOWS IN SECONDARY POOL 

; SECONDARY POOL WINDOW CONTROL AND MAPPING BLOCK 

: IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, LUTN2 POINTS 

H TO A CONTROL BLOCK IN SYSTEM POOL WHICH CONTAINS THE 

7 FOLLOWING CONTROL FIELDS AND THE MAPPING INFORMATION 

: FOR THE SECONDARY POOL WINDOW. 

; 

W.MAP: .BLKW 1 ; ADDR TO THE MAPPING PTRS IN SECONDARY POOL 


© me Ne Me Ne Oe Ne 


FORMAT 
=0 

ASSUME 

-BLKB 
W.USE: .BLKB 
W.VBN: .BLKB 
W.WISZ: .BLKB 

-BLKW 
W.RTRV: 

. ENDC 

« ENDC 

« ENDC 


a eT 


. ASECT 
L.LNK: .BLKW 
L.WI1l: .BLKW 


SECONDARY POOL WINDOW 
IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, THE RETRIEVAL 
POINTERS ARE MAINTAINED IN SECONDARY POOL IN THE FOLLOWING 


He PEE SS 


;PSSWND 
7SYS DEF 


7RSS11M 


LOCKED BLOCK LIST NODE 


.CTL, 0 


me Ne Ne Me te Ne 


“ee 


NUMBER OF ACTIVE MAPPING POINTERS 

STATUS OF BLOCK 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


END SECONDARY POOL WINDOW CONDITIONAL 
END SYSDEF CONDITIONAL 


END RSX-11M CONDITIONAL 


LINK TO NEXT NODE IN LIST 
POINTER TO WINDOW FOR FIRST ENTRY 


000004 
000005 
000006 


000010 


L.STD: 
L.VB1: 
L. VB2: 
L.CNT: 


L.LKSZ: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


-IF DF R$$11D 


- BLKW 
« BLKW 
-BLKW 
- BLKB 
- BLKB 


-IFF 
- BLKB 


- BLKB 
- BLKW 


~ENDC ;RS$$11D 


- PSECT 


HRPM NMH 


1 
1 
1 


we Ne Ne Ne te 


me te Ne 


POINTER TO STD OF TASK NODE CHARGED TO 
STARTING VBN OF FIRST ENTRY 

STARTING VBN OF SECOND ENTRY 

COUNT FOR FIRST ENTRY 

COUNT FOR SECOND ENTRY 


HIGH ORDER VBN BYTE 
COUNT FOR ENTRY 
LOW ORDER VBN 


000000 
000002 
000004 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
000036 
000040 
000042 
000044 
000046 
000050 
000052 
000054 
000056 
000060 
000061 
000062 
000064 
000065 
000066 
000072 
000074 
000076 


se Se te 


- =0 
H.CSP: 
H.HDEN: 
H. EFLM: 
H.CUIC: 
H.DUIC: 
H.IPS: 
H. IPC: 
H. ISP: 
H.ODVA: 
H.ODVL: 
H.TKVA: 
H.TKVL: 
H. PFVA: 
H.FPVA: 
H.RCVA: 
H. EFSV: 
H.FPSA: 
H.WND: 
H. DSW: 
H.FCS: 
H.FORT: 
H. OVLY: 
H. VEXT: 
H.SPRI: 
H.NML: 
H.RRVA: 
H. X25: 


H.GARD: 
H.NLUN: 
H. LUN: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


HDRDFS 


-ASECT 


~BLKW 
~BLKW 
~BLKW 
. BLKW 
- BLKW 
- BLKW 
. BLKW 
. BLKW 
- BLKW 
- BLKW 
- BLKW 
«BLEW 
- BLKW 
. BLKW 
- BLKW 
-BLKW 
- BLKW 
. BLKW 
- BLKW 
- BLKW 
-BLKW 
- BLKW 
-BLKW 
-BLKB 
.» BLKB 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
. BLKwW 


Ll eel NO el er ee 


HDRDF$ 


TASK HEADER OFFSET DEFINITIONS 


;CURRENT STACK POINTER 

;HEADER LENGTH IN BYTES 

;EVENT FLAG MASK WORD AND ADDRESS 
;CURRENT TASK UIC 

;DEFAULT TASK UIC 

7INITIAL PROCESSOR STATUS WORD (PS) 

7; INITIAL PROGRAM COUNTER (PC) 

;INITIAL STACK POINTER (SP) 

;ODT SST VECTOR ADDRESS 

;ODT SST VECTOR LENGTH 

7TASK SST VECTOR ADDRESS 

;TASK SST VECTOR LENGTH 

7POWER FAIL AST CONTROL BLOCK ADDRESS 
7FLOATING POINT AST CONTROL BLOCK ADDRESS 
7RECIEVE AST CONTROL BLOCK ADDRESS 
;EVENT FLAG ADDRESS SAVE ADDRESS 
7POINTER TO FLOATING POINT/EAE SAVE AREA 
;POINTER TO NUMBER OF WINDOW BLOCKS 
;TASK DIRECTIVE STATUS WORD 

7FCS IMPURE POINTER 

7;FORTRAN IMPURE POINTER 

;OVERLAY IMPURE POINTER 

7WORK AREA EXTENSION VECTOR POINTER 
;PRIORITY DIFFERENCE FOR SWAPPING 
;NETWORK MAILBOX LUN 

;RECEIVE BY REFERENCE AST CONTROL BLOCK ADDRESS 
;FOR USE BY X.25 SOFTWARE 

7;FIVE RESERVED BYTES 


; 

;POINTER TO HEADER GUARD WORD 
;NUMBER OF LUN'S 

;START OF LOGICAL UNIT TABLE 


000000 
000002 
000004 
000006 
000010 
000012 
000014 
000015 
000016 


000020 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


LENGTH OF FLOATING POINT SAVE AREA 


? 
; 
i 
H.FPSL=25.%*2 


i 
; WINDOW BLOCK OFFSETS 
; 


W.BPCB: .BLKW A. ;PARTITION CONTROL BLOCK ADDRESS 
W.BLVR: .BLKW i ;LOW VIRTUAL ADDRESS LIMIT 

W.BHVR: .~BLKW 1 ;HIGH VIRTUAL ADDRESS LIMIT 

W.BATT: .~BLKW 1 ;ADDRESS OF ATTACHMENT DESCRIPTOR 
W.BSIZ: .BLKW 1 ;SIZE OF WINDOW IN 32W BLOCKS 

W.BOFF: .~BLKW 1 ;PHYSICAL MEMORY OFFSET IN 32W BLOCKS 
W.BFPD: .BLKB 1 ;FIRST PDR ADDRESS 

W.BNPD: .BLKB 1 ;NUMBER OF PDR'S TO MAP 

W.BLPD: .BLKW 1 ;CONTENTS OF LAST PDR 

W.BLGH: ;LENGTH OF WINDOW DESCRIPTOR 


- PSECT 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


HWDDFS 


Oe 


MPCSR=177746 
MPAR=172100 
PIRQ=177772 
PRO=0 
PR1=40 

PR 4=200 
PR5=240 
PR6=300 
PR7=340 
PS=177776 
SWR=177570 
TPS=177564 


me Ne te 


-IF DF ESSEAE 


AC=177302 
MQ=177304 
SC=177310 


- ENDC 


se se 4 


~IF DF MS$SMGE 


KDSAR 0=1 72 360 
KDS DR O=172 320 
KISAR0=172 340 
KINARO=KISARO 
KISAR5=172 352 
KINAR5=KISAR5 
KISAR6=1 72354 
KINAR6=KISAR6 
KISAR7=1 72356 
KINAR7=KISAR7 
KISDRO0=172 300 
KISDR6=1 72314 
KISDR7=172316 
SISDRO=172200 
UDSAR0=1 77660 
UDS DRO=177620 
UISARO=177640 
UISAR4=177650 
UISAR5=177652 
UISAR6=177654 
UISAR7=177656 
UISDRO=177600 


HARDWARE REGISTER ADDRESSES AND STATUS CODES 


HWDDF$ 


;ADDRESS OF PDP-11/70 MEMORY PARITY REGISTER 
;ADDRESS OF FIRST MEMORY PARITY REGISTER 
;PROGRAMMED INTERRUPT REQUEST REGISTER 


; PROC 
; PROC 
; PROC 
7 PROC 


ESSOR PRIORITY 
ESSOR PRIORITY 
ESSOR PRIORITY 
ESSOR PRIORITY 


;PROCESSOR PRIORITY 


7 PROC 
7; PROC 


ESSOR PRIORITY 


ESSOR STATUS WORD 


SNUB RO 


CONSOLE SWITCH AND DISPLAY REGISTER 
;CONSOLE TERMINAL PRINTER STATUS REGISTER 


EXTENDED ARITHMETIC ELEMENT REGISTERS 


; ACCUMULATOR 


;MULTIPLIER-QUOTIENT 


;SHIF 


; KERN 


; KERNEL 


; KERN 
; KERN 
; KERN 


7 KERNEL 
7; KERNEL 
; KERNEL 


; KERN 
; KERN 
; KERN 
; KERN 


; KERNEL 
;SUPERVISOR I 


;USER 
;USER 
:USER 
;USER 
3;USER 
; USER 
;USER 
; USER 


T COUNT 


EL PAR 
PDR 
PAR 
PAR 
PAR 
PAR 
PAR 
PAR 
PAR 
PAR 
PDR 
PDR 
PAR 


EL 
EL 
EL 


EL 
EL 
EL 
EL 


HHHHHHHHHHHOY 
WANDWINANDANUNGCOCCS 


DR 0 
PAR 0 

PDR 
PAR 
PAR 
PAR 
PAR 
PAR 
PDR 


HHHHHHUY 
ONDUBOO 


MEMORY MANAGEMENT HARDWARE REGISTERS AND STATUS CODES 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


UISDR4=177610 ;USER I PDR 4 
UISDR5=177612 ;USER I PDR 5 
UISDR6=177614 ;USER I PDR 6 
UISDR7=177616 7;USER I PDR 7 
UBM PR=170200 ;UNIBUS MAPPING REGISTER 0 
CMODE=1 40000 ;CURRENT MODE FIELD OF PS WORD 
PMODE=30000 ;PREVIOUS MODE FIELD OF PS WORD 
SRO=177572 ;SEGMENT STATUS REGISTER 0 
SR3=172516 ;SEGMENT STATUS REGISTER 3 

~ENDC ;MSSMGE 
i 
} FEATURE SYMBOL DEFINITIONS 
, 
FE. EXT=1 ;22-BIT EXTENDED MEMORY SUPPORT 
FE.MUP=2 ;MULTI-USER PROTECTION SUPPORT 
FE. EXV=4 ; EXECUTIVE IS SUPPORTED TO 20K 
FE.DRV=10 | ; LOADABLE DRIVER SUPPORT 
FE. PLA=20 7PLAS SUPPORT 
FE.CAL=40 ;DYNAMIC CHECKPOINT SPACE ALLOCATION 
FE. PKT=100 ;PREALLOCATION OF I/O PACKETS 
FE. EXP=200 7 EXTEND TASK DIRECTIVE SUPPORTED 
FE. LSI=400 ;PROCESSOR IS AN LSI-11 
FE, OFF=1000 ;PARENT OFFSPRING TASKING SUPPORTED 
FE. FDT=2000 ; FULL DUPLEX TERMINAL DRIVER 
FE, X25=4000 3X.25 COM EXECUTIVE LOADED (1=YES) 
FE. DYM=10000 ;DYNAMIC MEMORY ALLOCATION SUPPORTED 
FE. CEX=20000 ;COM EXEC IS LOADED 
FE.MXT=40000 7;MCR EXIT AFTER EACH COMMAND MODE 
FE.NLG=100000 ;LOGINS DISABLED - MULTI-USER SUPPORT 


SECOND FEATURE MASK SYMBOL DEFINITIONS 


oe Me Ne 


‘ 

F2.DAS=1 ;KERNEL DATA SPACE (M-PLUS ONLY) 
F2, LIB=2 ;SUPERVISOR MODE LIBRARIES " 
F2.MP=4 ;MULTIPROCESSING SUPPORT « 

F2. EVT=10 ;EVENT TRACE SUPPORT " 

F2. ACN=20 7CPU ACCOUNTING " 
F2.SDwW=40 ;SHADOW RECORDING 

F2,. POL=100 ; SECONDARY POOLS 7 
F2.WND=200 ; SECONDARY POOL FILE WINDOWS ¥ 
F2.DPR=400 ;DIRECTIVE PARTITION SUPPORT 

F2. IRR=1000 ; INSTALL, REQUEST AND REMOVE SUPPORT 
F2,.GGF=2000 ;GROUP GLOBAL EVENT FLAG SUPPORT 

F2. RAS=4000 ;RECEIVE/SEND DATA PACKET SUPPORT 

F 2. AHR=10000 ;ALT. HEADER REFRESH AREAS SUPPORTED 
F2. RBN=20000 ;ROUND ROBIN SCHEDULING SUPPORT 

F 2, SWP=40000 ; EXECUTIVE LEVEL DISK SWAPPING SUPPORT 
F2,STP=100000 ; EVENT FLAG MASK IS IN THE TCB (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


0 se Ne 


Lé 

F3.CRA=1 
F3.NWK=2 

F3, EIS=4 
F3.STM=10 
F3.UDS=20 
F3, PRO=40 
F3. XHR=100 
F3.AST=200 
F3.11S5=400 
F3.CLI=1000 
F3.TCM=2000 
F3.PMN=4000 
F3.WAT=10000 
F3.RLK=20000 


me Se Ne 


HF. UBM=1 
HF. EIS=2 
HF.CIS=200 


HF. FPP=100000 


HARDWARE FEATURE MASK 


THIRD FEATURE MASK SYMBOL DEFINITIONS 


7SPONTANEOUS CRASH (1=YES) 

7SYSTEM HAS NETWORK SUPPORT 

7SYSTEM REQUIRES THE EXTENDED INST. SET 
;SYSTEM HAS SET SYSTEM TIME DIRECTIVE 
;USER DATA SPACE (M-PLUS ONLY) 

7PROTO TCBS OUT OF POOL " 

; EXTERNAL HEADER SUPPORT " 

7;SYSTEM HAS AST SUPPORT 

7;SYSTEM IS RSX-115S 

7;SYSTEM HAS MULTIPLE CLI SUPPORT 
;TERMINAL COMMON (M-PLUS ONLY) 

7POOL MONITORING SUPPORT 

;WATCHDOG TIMER SUPPORT 

; 'RMS' RECORD LOCKING SUPPORT 


SYMBOL DEFINITIONS 


;SYSTEM HAS A UNIBUS MAP (1=YES) 
*;SYSTEM HAS EXTENDED INSTRUCTION SET 
;SYSTEM HAS COMMERCIAL INSTRUCTION SET 
7SYSTEM SUPPORTS FLOATING POINT (1=NO) 


-=0 
000000 X.LNK: 
000002 xX.JSR: 
000006 X.PSW: 
000007 
000010 X.ISR: 
000012 X.FORK: 
000012 
000014 
000016 
000020 
X. REL: 
X.DSTI: 
X.TCB: 
X, AST: 
X. VEC: 
X. VPC: 
X. LEN: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


ITBDFS$ 


-IF DF 


-MCALL 
PRTDFS 


- ENDC 
~ASECT 
- BLKW 
JSR 

- BLKB 
. BLKB 
~ BLKW 
- BLKW 
. BLKW 
- BLKW 
«BLEW 
-IF DF 
- BLKW 
« ENDC 


- BLKW 
. BLKW 


-IF NB 
IF DF 


. BLKW 
- BLKB 


. ENDC 
- BLKW 


- BLKW 


. ENDC 


- PSECT 


,, oYSDEF 


ASSTRP 


PKTDFS$ 


;ASSTRP 


ee 


MSSMGE 
1 
;MSSMGE 


1 
1 


SYS DEF 
ASSTRP 


1 
A. PRM 


;ASSTRP 
al 


aE 


;SYS DEF 


= 


Me Ne Ne Ne Ne Se Ne te MO Ne 


~ 


mee 


me Ne 


ee TY 


INTERRUPT TRANSFER BLOCK (ITB) OFFSET DEFINITIONS 


DEFINE AST BLOCK OFFSETS 


LINK WORD FOR ITB LIST STARTING IN TCB 
CALL SINTSC 

LOW BYTE OF PSW FOR ISR 

UNUSED 

ISR ENTRY POINT (APR5 MAPPING) 

FORK BLOCK 

THREAD WORD 

FORK PC 

SAVED R5 

SAVED R4 


RELOCATION BASE FOR ABR5 


ADDRESS OF DIS.INT. ROUTINE 
TCB ADDRESS OF OWNING TASK 


A.DQSR FOR AST BLOCK 
AST BLOCK 


VECTOR ADDRESS (IF AST SUPPORT, 

THIS IS FIRST AND ONLY AST PARAMETER) 
SAVED VECTOR PC 

LENGTH IN BYTES OF ITB 


000000 
000002 
000004 
000005 
000006 
000010 


000012 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


LCBDFS 


me We Ne 8 te te te te 


~ASECT 
-=0 
L.LINK: .BLKW 
L.NAM: .BLKW 
L.UNIT: .BLKB 
L.TYPE: .BLKB 
L.UCB: .BLKW 
L.ASG: .BLKW 


L, LGTH=, -L. LNK 


-PSECT 


ee 


LCBDF$ 


LOGICAL ASSIGNMENT CONTROL BLOCK 


THE LOGICAL ASSIGNMENT CONTROL BLOCK (LCB) IS USED TO ASSOCIATE A 
LOGICAL NAME WITH A PHYSICAL DEVICE UNIT. LCB'S ARE LINKED TOGETHER 
TO FORM THE LOGICAL ASSIGNMENTS OF A SYSTEM. ASSIGNMENTS MAY BE ON 
A SYSTEM WIDE OR LOCAL (TERMINAL) BASIS, 


7LINK TO NEXT LCB 

;LOGICAL NAME OF DEVICE 
;LOGICAL UNIT NUMBER 

7;TYPE OF ENTRY (O=SYSTEM WIDE) 
;TI UCB ADDRESS 

;ASSIGNMENT UCB ADDRESS 


;LENGTH OF LCB 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


MTADF$ 


MTADFS$ 


ANSI MAGTAPE SPECIFIC DATA STRUCTURES 
VOLUME SET CONTROL BLOCK OFFSET DEFININTIONS (VSCB) 


VOLUME SET AND PROCESS CONTROL SECTION 


me Ne 0 Ne Ne NO te 


-ASECT 

-=0 
000000 V.TCNT: .BLKW 1 7TRANSACTION COUNT 
000002 V.TYPE: .BLKB 1 ; VOLUME TYPE DESCRIPTOR 
000003 V.VCHA: .BLKB 1 ; VOLUME CHARACTERISTICS 
000004 V.LABL: .BLKB 12. ;FILE SET ID (FIRST SIX BYTES) 
000020 V.NXT: .BLKW ut ;PTR TO NEXT VSCB NODE 
000022 V.MVL: .BLKW 1 7;PTR TO MOUNTED VOL LIST 
000024 V.UVL: .BLKW 1 ;PTR TO UNMOUNTED VOL LIST 
000026 V.ATL: .BLKW 1 ;ATL ADDR OF ACCESSING TASK TCB IN RSX11M 
000030 V.UCB: .BLKW 1 7;ADDR OF CURRENT UCB OR PUD 
000032 V.RVOL: .BLKB 1 ;CURRENT RELATIVE VOL # 
000033 V.MOU: .BLKB 1 ;MOUNT MODE BYTE 
000034 V.TCHR: .BLKW 1 ;UINT CHAR. FOR ALL UNITS USED FOR VOL SET 
000036 V.SEON: .BLKW 1 ;CURRENT FILE SEQUENCE # 
000040 V.SECN: .BLKW 1 ;CURRENT FILE SECTION # 
000042 V.TPOS: .BLKB al ;POSITION OF TAPE IN TM'S TO NXT HDR1 
000043 V.PSTA: .BLKB al 7PROCESS STATUS BYTE 
000044 V.TIMO: .BLKW 1 :;BLOCKED PROCESS TIMEOUT COUNTER 
000046 V.STAT: .BLKW 3 ;STATUS WORDS USED BY COMMAND EXECUTION MODULES 
000054 V.TRTB: .BLKB 1 ;TRANSLATION CONTROL BYTE 
000055 V.EFTV: .BLKB 1 ;FOR MAG TO RETURN IE.EOF, EOT, EOV 


LABEL DATA SECTION 


we Ne me 


000056 V.BLKL: .BLKW Al ;BLOCK LENGTH 

000060 V.RECL: .BLKW 1 ;RECORD LENGTH 

000062 V.FNAM: .BLKW 3 ;FILE NAME 

000070 V.FTYP: .BLKW 1 ;FILE TYPE 

000072 V.FVER: .BLKW 1 ;FILE VERSION # 

000074 V.CDAT: .BLKW 2 ;CREATION DATE 

000100 V.EDAT: .~BLKW 2 ;EXPRIATION DATE 

000104 V.BLKC: .BLKW 2 ;BLOCK COUNT FOR FILE SECTION 
000110 V.RTYP: .BLKB 1 ;RECORD TYPE 

000111 V.FATT: .BLKB 1 ;FILE ATTRIBUTES FOR CARRIAGE CONTROL 
000112 . BLKB 30. ;REMAINDER OF FILE ATTRIBUTES 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


NULL WINDOW SECTION 


=e Ne Ne 


000150 V.WIND: .BLKW 
000160 V.MST2: .BLKW 
000162 V.FABY: .BLKB 
000163 - BLKB 
000164 V.ANSN: .BLKB 
000205 V.BOFF: .BLKB 
000206 V.DENS: .BLKB 
000207 'V.DRAT: .BLKB 
000210 V.DBLK: .BLKW 
000212 V.DREC: .BLKW 


;NULL WINDOW 

#MAGTAPE STATUS BITS 

;FILE ACCESSIBILITY BYTE (HDR1) 
7SPARE 

sANSI 17 CHARACTER FILE NAME 
;BUFFER OFFSET 

7;REQUESTED UNIT DENSITY 
;DEFAULT RECORD ATTRIBUTES 
7DEFAULT BLOCK SIZE 

;DEFAULT RECORD SIZE 


eee 


BRE REPRE 
~J 
e 


000214 S.VSCB=, 7SIZE OF VSCB 


«PSECT 


DEFINE OFFSETS INTO NULL WINDOW SECTION 


we Ne we 


- ASECT 
-=0 
000000 W.CTL: .BLKwW 1 7;CONTROL WORD IN WINDOW 
V.WINC=V.WIND4+.CTL ;CNTRL WORD IN NULL WINDOW 
;RELATIVE TO THE VSCB 
-PSECT 


MOUNTED VOLUME LIST OFFSET DEFININTIONS (MVL) 


at Ty 


-ASECT 
-=0 
-IF DF RSS11M 
000000 M.NXT: .BLKW 1 7;PTR TO NXT MVL NODE (11M) 


-ENDC ;RSS11M 
000002 M.UIC: .BLKW 1l ;OWNER UIC FROM RVOL #1 
000004 M.CH: - BLKwW 1 7U.CH/U.VP (11D) 
000006 M.PROT: .BLKW 1 ;PROTECTION U.AR IN 11D 
-IF NDF RSS11M 


~BLRW 2 7;ACP WORDS 11D 
M.NXT: .BLKW 1 7;PTR TO NEXT MVL NODE (11D) 


-ENDC ;RS$11M 
000010 M.RVOL: .BLKB 1 ;RELATIVE VOL # OF MOUNTED VOLUME 
000011 M.STAT: .BLKB dl ;VOLUME STATUS 
000012 M.VIDP: .BLKW 1 7VOLUME ID POINTER 
000014 M.UCB: .BLKW 1 7ADDR OF ASSOC UCB OR PUD 


000016 S.MVL=. 7SIZE OF MVL NODE 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


UNMOUNTED VOLUME AND VOLUME LIST OFFSET DEFINITIONS (UVL) 


se me we 


~ASECT 

- =0 
000000 L.NXT: .BLKW 1 ;PTR TO NXT UVL NODE 
000002 L.VOLi: .BLKB 1 ;REL VOL # OF 1'ST VOL IN NODE 
000003 L.VOL2: .BLKB 1 ;REL VOL # OF 2'ND VOL IN NODE 
000004 L.VID1: .BLKB 6 ;VOL ID OF 1'ST VOL IN NODE 
000012 L.VID2: .BLKB 6 :;VOL ID OF 2'ND VOL IN NODE 
000020 S.UVL=. ;SIZE OF UVL NODE 


» PSECT 


=e Ne 


SYSTEM DATA STRUCTURE CONTENT VALUES 


=e 


VSCB VALUES 


V.MOU VALUES 


ee te te me 


VM.OLD = 200 ;OLD .FL300 VOLUME -- VM.BYP WILL ALSO BE SET 
VM.BYP = 100 ;BYPASS LABEL PROCESSING 
VWM.ULB = 40 ; UNLABELED TAPE 
VWM.FSC = 20 ;OVERRIDE FILE SET ID CHECK 
VM.EXC = 10 ;OVERRIDE EXPRIATION DATE CHECK 
7 
; V.MST2 VALUES 
' 
V2.INI = 1 ;MAG WANTS US TO INITIALIZE NEXT OUTPUT 
V2.XH2 = 2 :THIS FILE HAS NO HDR2, DON'T WRITE EOF2 
V2.XH3 = 4 ;THIS FILE HAS NO HDR3, DON'T WRITE EOF3 
V2.NH3) = 10 ;DON'T WRITE HDR3/EOX3 LABELS 
V2.0AC = 20 ; OVERRIDE FILE/VOLUME ACCESSIBILITY 
7 
; V.PSTA VALUES - UNBLOCKED TRANSITION STATE 
t 
VP. RM = 2 ;READ DATA MODE 
VP.WM = 4 ;WRITE DATA MODE 
VP.UCM = 6 ; UNLABELLED CREATE POSITIONING MODE 
VP.SM = 10 ;SEARCH MODE 
VP.MOU = 20 ;MOUNT MODE 
VP.RWD = 40 ;REWIND OR VOL VERIFICATION WAIT 
VP.VFY = VP. RWD 
VP.POS = 100 ;PROCESS IN POSITIONING MODE 
; (MULTI-SECTION FILE) 
BLOCKED STATE = -(UNBLOCKED TRANSITION STATE VALUES) 


PROCESS TIMED OUT BIT 0 =1 


<i me se te te Ne 


P.TO=1 


ose Ne 


‘ 
WI. RDV 


WI.WRV 


WI. EXT 
WI.LCK 


; MVL VALUES IN 


f 

MS. VER 
MS.RID 
MS.NMO 
MS. TMO 
MS. EXP 


MISC 


ome Ne 


f 

MO. OVR 
MO.UIC 
MO. PRO 
MO. 160 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


400 

1000 
2000 
4000 


200 


10 


NULL WINDOW CONTROL BIT DEFINITIONS 


;ACCESSED FOR READ 
;ACCESSED FOR WRITE 
;ACCESSED FOR EXTEND 
; LOCKED 


THE M.STAT FIELD 


;VOL ID NOT VERIFIED 

;VOL ID TO BE READ NOT CHECKED 
;MOUNT MESSAGE NOT GIVEN YET 
;ONE TIMEOUT ALREADY EXPRIED 

; EXPIRATION DATE MESSAGE GIVEN 


BITS USED IN MOUNT (STORED IN V.STS) 


Pos tH 


;OVER RIDE VOL NAME SWITCH 
;EXPLICIT UIC GIVEN 
;EXPLICIT PROTECTION GIVEN 
31600 BPI SPECIFIED 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


PCBDF$ 


PCBDFS ,,SYSDEF 


PARTITION CONTROL BLOCK OFFSET DEFINITIONS 


et Ty 


~ASECT 
- =0 
000000 P.LNK: .BLKW 
000002 P.PRI: .BLKB 
000003 P.I0C: .BLKB 
000004 P.NAM: .BLKW 
000010 P.SUB: .BLKW 
000012 P.MAIN: .~.BLKW 


;LINK TO NEXT PARTITION PCB 
PRIORITY OF PARTITION 

71/0 + I/O STATUS BLOCK COUNT 
;PARTITION NAME IN, RAD50 
;POINTER TO NEXT SUBPARTITION 
;POINTER TO MAIN PARTITION 


PREM EE 


-IF NB SYSDEF 
.IF NDF MSSMGE 
P. HDR: 7;POINTER TO HEADER CONTROL BLOCK 
»ENDC ;MSSMGE 
- IFTF 
000014 P.REL: .BLKW al ;STARTING PHYSICAL ADDRESS OF PARTITION 


000016 P.BLKS: 


000016 P.SIZE: .BLKW 1 SIZE OF PARTITION IN: 


i 
; UNMAPPED SYSTEMS - BYTES 
‘ 


MAPPED SYSTEMS - 32 WORD BLOCKS 

000020 P.WAIT: .BLKW 1 7PARTITION WAIT QUEUE LISTHEAD (2 WORDS) 
000022 P.SWSZ: .BLKW 1 ;PARTITION SWAP SIZE (SYSTEM ONLY) 
000024 P.BUSY: .BLKB 2 7PARTITION BUSY FLAGS 
000026 P.OWN: 
000026 P.TCB: .BLKW 1 7TCB ADDRESS OF OWNER TASK 
000030 P.STAT: .BLKW 1 ;PARTITION STATUS FLAGS 

IFT 


IF DF MSSMGE 
P.HDR: .BLKW 1 ;POINTER TO HEADER CONTROL BLOCK 
~ENDC ;MSSMGE 


P.PRO: .BLKW a ;PROTECTION WORD [DEWR, DEWR, DEWR, DEWR] 
P.ATT: .BLKW 2 ;ATTACHMENT DESCRIPTOR LISTHEAD 


.IF NDF PSSLAS 


P. LGTH=P. PRO 7;LENGTH OF PARTITION CONTROL BLOCK 


000000 
000002 
000003 
000004 
000006 
000010 
000011 
000012 


000014 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- IFF 

P. LGTH=. 
~-ENDC ;PSSLAS 
~IFF 


-PSECT 


PARTITION STATUS WORD 


o Ne Ne 


PS.OUT=100000 
PS.CKP=40000 
PS.CKR=20000 
PS.CHK=10000 
PS.FXD=4000 
PS. PER=2000 
PS.LIO=1000 
PS.NSF=400 
PS.COM=200 
PS. PIC=100 
PS.SYS=40 
PS. DRV=20 
PS.DEL=10 


PS.APR=7 


ATTACHMENT DESCRIPTOR 


me Ne Ne 


. ASECT 
- =0 
A.PCBL: .BLKW 1 
A.PRI: .BLKB 1 
A.IOC: .BLKB 1 
A.TCB: .BLKW 1 
A.TCBL: .BLKW 1 
A.STAT: .BLKB 1 
A.MPCT: .BLKB 1 
A. PCB: .BLKW 1 
A. LGTH=,. 
i 
; ATTACHMENT DESCRIPTOR 
La 

»PSECT 
AS.DEL=10 
AS. EXT=4 
AS.WRT=2 
AS. RED=1 


-ENDC ;SYSDEF 


;LENGTH OF PARTITION CONTROL BLOCK 


BIT DEFINITIONS 


;PARTITION IS OUT OF MEMORY (1=YES) 
;PARTITION CHECKPOINT IN PROGRESS (1=YES) 
;PARTITION CHECKPOINT IS REQUESTED (1=YES) 
;PARTITION IS NOT CHECKPOINTABLE (1=YES) 
;PARTITION IS FIXED (1=YES) 

;PARITY ERROR IN PARTITION (1=YES) 

;MARKED BY SHUFFLER FOR LONG I/O (1=YES) 
;PARTITION IS NOT SHUFFLEABLE (1=YES) 

;LIBRARY OR COMMON BLOCK (1=YES) 

;POSITION INDEPENDENT LIBRARY OR COMMON (1=YES) 
;SYSTEM CONTROLLED PARTITION (1=YES) 

;DRIVER IS LOADED IN PARTITION (1=YES) 
;PARTITION SHOULD BE DELETED WHEN NOT ATTACHED 
; (1=YES) 

;STARTING APR NUMBER MASK 


OFFSETS 


;PCB ATTACHMENT QUEUE THREAD WORD 
;PRIORITY OF ATTACHED TASK 

;1/0 COUNT THROUGH THIS DESCRIPTOR 

;TCB ADDRESS OF ATTACHED TASK 

;TCB ATTACHMENT QUEUE THREAD WORD 

;STATUS BYTE 

;MAPPING COUNT OF TASK THRU THIS DESCRIPTOR 
;PCB ADDRESS OF ATTACHED TASK 


;LENGTH OF ATTACHMENT DESCRIPTOR 


STATUS BYTE BIT DEFINITIONS 


;TASK HAS DELETE ACCESS (1=YES) 
;TASK HAS EXTEND ACCESS (1=YES) 
;TASK HAS WRITE ACCESS (1=YES) 
;TASK HAS READ ACCESS (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


PKTDFS$ 


177774 
177776 
000000 
000002 


000004 
000006 
000010 
000012 


PKTDFS 


ASYNCHRONOUS SYSTEM TRAP CONTROL BLOCK OFFSET DEFINITIONS 


SOME POSITIONAL DEPENDENCIES BETWEEN THE OCB AND THE AST CONTROL 
BLOCK ARE RELIED UPON IN THE ROUTINE S$FINXT IN THE MODULE SYSXT. 


we Ne te te Se Ne 


- ASECT 
-=177774 
A.KSR5: .BLKW 
A.DOSR: .BLKW 

- BLKW 
A.CBL: .BLKW 


;SUBROUTINE KISAR5 BIAS (A.CBL=0) 

;DEQUEUE SUBROUTINE ADDRESS (A.CBL=0) 

7;AST QUEUE THREAD WORD 

;LENGTH OF CONTROL BLOCK IN BYTES 

7IF A.CBL = 0, THE AST CONTROL BLOCK IS 

;TO BE DEALLOCATED BY THE DEQUEUE SUBROUTINE 
;POINTED TO BY A.DOQSR MAPPED VIA APR 5 
;VALUE A.KSR5. THIS IS CURRENTLY USED ONLY 
7;BY THE FULL DUPLEX TERMINAL DRIVER FOR 
;UNSOLICITED CHARACTER ASTS. 

;IF THE LOW BYTE OF A.CBL = 0, AND THE 

;HIGH BYTE IS NOT = 0, THE AST CONTROL BLOCK 
71S A SPECIFIABLE AST, WITH LENGTH, C.LGTH. 
;IF THE HIGH BYTE OF A.CBL = 0 AND THE LOW 
7;BYTE > 0, THEN THE LOW BYTE IS THE LENGTH 
;OF THE AST CONTROL BLOCK. IF THE HIGH BYTE 
;OF A.CBL = 0 AND THE LOW BYTE IS NEGATIVE, 
;THIS IS A KERNEL AST. SEE BELOW FOR 

7A DESCRIPTION OF A.CBL FOR KERNEL ASTS. 
;NUMBER OF BYTES TO ALLOCATE ON TASK STACK 
;AST TRAP ADDRESS 

7;NUMBER OF AST PARAMETERS 

;FIRST AST PARAMETER 


Heeb 


A.BYT: .BLKW 
A.AST: .BLKW 
A.NPR: .BLKW 
A.PRM: .BLKW 


a 


THE SPECIFIABLE AST CODES MUST NOT BE 0. 


eNews 


e 
AS.FPA=1] ;CODE FOR FLOATING POINT AST 


AS. RCA=2 ;CODE FOR RECEIVE DATA AST 

AS. RRA=3 7CODE FOR RECEIVE BY REFERENCE AST 

AS. PFA=4 7CODE FOR POWERFAIL AST 

AS. REA=5 7CODE FOR REQUESTED EXIT (ABORT) AST 
AS. CAA=6 ;CODE FOR COMMAND ARRIVAL AST FOR CLIS 


ABORTER SUBCODES FOR ABORT AST (AS.REA) TO BE RETURNED ON USER'S 
STACK 


ee te Ne 


AB.NPV=1 ;ABORTER IS NONPRIVILEGED (1=YES) 
AB. TYP=2 ;ABORT FROM DIRECTIVE (0=YES) 
;ABORT FROM CLI COMMAND (1=YES) 


C-32 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


KERNEL AST CONTROL BLOCK DEFINITIONS 

THE LOW BYTE OF A.CBL FOR A KERNEL AST HAS THE FOLLOWING FORMAT: 
BIT #200 ALWAYS EQUALS 1 
BIT #100 IS ZERO IF $SGFIN MUST BE CALLED DURING AST PROCESSING 
THE REMAINING SIX BITS ARE USED AS THE KERNEL AST TYPE FIELD 


BECAUSE THERE ARE ONLY 6 BITS AVAILABLE TO THE KERNEL AST 
INDEX FIELD, ONLY (2**6)-1 KERNEL AST TYPES ARE POSSIBLE. 


me SO Ne we Se Se te te te Ne me 


= 


AK. BUF=200 ;BUFFERED I/O COMPLETION AST 
AK, OCB=201 ;OFFSPRING EXIT 

AK.GBI=202 ;GENERAL BUFFERED I/O AST 

AK. TBT=203 ;TASK FORCED T-BIT TRAP AST 

AK. DIO=204 ;DELAYED I/O (M-PLUS COMPATIBLE) 


OFFSPRING CONTROL BLOCK DEFINITIONS 


SOME POSITIONAL DEPENDENCIES EXIST BETWEEN THE OCB AND THE AST 
CONTROL BLOCK IN ROUTINE S$FINXT IN MODULE SYSxXT 


ee Ne Se te Ne MO 


=0 
000000 O.LNK: .BLKW A ;O0CB LINK WORD 
000002 O.MCRL: .BLKW 1 ;ADDRESS OF MCR COMMAND LINE 
000004 O.PTCB: .BLKW a ;PARENT TCB ADDRESS 
000006 O.AST: .BLKW 1 ;EXIT AST ADDRESS 
000010 O.EFN: .BLKW 1 ;EXIT EVENT FLAG 
000012 O.ESB: .BLKW 1 ;EXIT STATUS BLOCK VIRTUAL ADDRESS 
000014 O.STAT: .BLKW 8. ;EXIT STATUS BUFFER 
000034 O.LGTH=. ;LENGTH OF OCB 


I/O PACKET OFFSET DEFINITIONS 


a Ty 


- ASECT 
-=0 


000000 I.LNK: .BLKW 1 31/0 QUEUE THREAD WORD 

000002 I.PRI: .BLKB 1 ;REQUEST PRIORITY 

000003 I.EFN: .BLKB 1 ;EVENT FLAG NUMBER 

000004 I.TCB: .BLKW 1 ;TCB ADDRESS OF REQUESTOR 

000006 I.LN2: .BLKW 1 ;POINTER TO SECOND LUN WORD 

000010 I.UCB: .BLKW 1 ;POINTER TO UNIT CONTROL BLOCK 

000012 I.FCN: .BLKW 1 71/0 FUNCTION CODE 

000014 I.IOSB: .BLKW 1 ;VIRTUAL ADDRESS OF I/O STATUS BLOCK 

000016 - BLKW 1 71/0 STATUS BLOCK RELOCATON BIAS 

000020 .- BLKW 1 71/0 STATUS BLOCK ADDRESS 

000022 I.AST: .BLKW 1 ;AST SERVICE ROUTINE ADDRESS 

000024 I.PRM: .BLKW 1 ;RESERVED FOR MAPPING PARAMETER #1 

000026 - BLKW 6 ;PARAMETERS 1 TO 6 

000042 - BLKW 1 ;USER MODE DIAGNOSTIC PARAMETER WORD 

000044 I.ATTL=. ;MINIMUM LENGTH OF I/O PACKET (USED BY 
;FILE SYSTEM TO CALCULATE MAXIMUM 
;NUMBER OF ATTRIBUTES) 

000044 I.LGTH=. ;LENGTH OF I/O REQUEST CONTROL BLOCK 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


; GROUP GLOBAL EVENT FLAG CONTROL BLOCK OFFSETS 


; 
c 
; 
000000 G.LNK: .BLKw 


=0 
1 ;LINK WORD 
000002 G.GRP: .BLKB 1 ;GROUP NUMBER 
000003 G.STAT: .BLKB 1 ;STATUS BYTE 
000004 G.CNT: .BLKW 1 ;ACCESS COUNT 
000006 G.EFLG: .BLKW 2 ;EVENT FLAGS 
000012 G.LGTH=. ;LENGTH OF GROUP GLOBAL CONTROL BLOCK 


; 

; STATUS BYTE DEFINITIONS 

; 

GS. DEL=1 ;GROUP MARKED FOR DELETE 

; 

; EXECUTIVE POOL MONITOR CONTROL FLAGS 

i 

3 

; SPOLST IS THE SYNCHRONIZATION WORD BETWEEN THE EXEC AND POOL MONITOR 
? 

PC. HIH=1 7HIGH POOL LIMIT CROSSED (1=YES) 

PC. LOW=2 ;LOW POOL LIMIT CROSSED (1=YES) 
PC.ALF=4 7POOL ALLOCATION FAILURE (1=YES) 
PC.NRM=PC.HIH*400 ;POOL TASK INHIBIT BIT FOR HIGH POOL 
PC. ALM=PC. LOW*400 7POOL TASK INHIBIT BIT FOR LOW POOL 
i 

7 SPOLFL IS THE POOL USAGE CONTROL WORD 

; 

PF.INS=40 ;REJECT NONPRIVILEGED INS/RUN/REM 
PF. LOG=100 ;LOGINS ARE DISABLED 

PF. REQ=200 ;STALL REQUEST OF NONPRIV. TASKS 

PF. ALL=177777 ;TAKE ALL POSSIBLE ACTIONS TO SAVE POOL 


? 
; CLI PARSER BLOCK (CPB) DEFINITIONS 
7 


=0 
000000 C.PTCB: .BLKwW 
000002 C.PNAM: .BLKW 
000006 C.PSTS: .BLKW 
000010 C.PDPL: .BLKB ;LENGTH OF DEFAULT PROMPT 
000011 C.PCPL: .BLKB ;LENGTH OF CNTRL/C PROMPT 
000012 C.PRMT: ;START OF ASCII PROMPT STRINGS 
;THE DEFAULT STRING IS CONCANTENATED 
;WITH THE “C STRING 


;ADDRESS OF CLI'S TCB 
7;CLI NAME 
;STATUS MASK 


Pee NOH 


000000 
000002 
000004 
000006 
000007 
000010 
000012 
000013 


000014 


000010 
000012 
000014 
000016 
000020 
000022 
000024 
000030 


000032 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


STATUS 


ome Ne 


a 

CP.NUL=1 
CP.MSG=2 
CP. LGO=4 
CP.DSB=10 
CP. PRV=20 
CP. SGL=40 
CP.NIO=100 


CP. RST=200 


CP. EXT=400 


me Se Ne TO Se 


CODES 128. 


f 

CM. INE=1 
CM. IND=2 
CM.CEN=3 
CM.CDS=4 
CM. ELM=5 
CM. EXT=6 
CM. LKT=7 
CM.RMT=8. 
CM.MSG=9. 


A.DIS: .BLKW 
A.MAS: .BLKW 
A.NUM: 


A.LIN: .BLKW 
A.ACC: .BLKB 
A.STA: .BLKB 


A. LEN1=, 

»=A.LIN 

A.IMAP: .~BLKW 
A,IBUF: .BLKW 
A.ILEN: .BLKW 
A.SMAP: .BLKW 
A.SBUF: .BLKW 
A.SLEN: .BLKW 
A.I0S: .BLKW 
A.RES: .BLKW 
A, LEN2=. 


CODES 0 - 127. 
- 255. 


BIT DEFINITIONS 


;PASS EMPTY COMMAND LINES TO CLI 

;CLI DESIRES SYSTEM MESSAGES 

;CLI WANTS COMMANDS FROM LOGGED OFF TTYS 
;CLI IS DISABLED 

;USER MUST BE PRIV TO SET TTY TO THIS CLI 
:DON'T HANDLE CONTINUATIONS (M-PLUS ONLY) 
:MCR..., HEL, BYE DO NO I/O TO TTY 

;HEL, BYE ALSO DO NOT SET CLI ETC. 
;ABILITY TO SET TO THIS CLI [5 RESTRICTED 
;TO THE CLI ITSELF 

;PASS TASK EXIT PROMPT REQUESTS TO CLI 


IDENTIFIER CODES FOR SYSTEM TO CLI MESSAGES. 


ARE RESERVED FOR USE BY DIGITAL, 


PPP ERP PEE 


we 


ARE 


RESERVED FOR USE BY CUSTOMERS 


INITIALIZED ENABLED 
INITIALIZED DISABLED 
ENABLED 

DISABLED 

BEING ELIMINATED 

;CLI MUST EXIT IMMEDIATELY 
;NEW TERMINAL LINKED TO CLI 
;TERMINAL REMOVED FROM CLI 
gGENERAL MESSAGE TO CLI 


;CLI 
;CLI 
7CLI 
;CLI 
;CLI 


;ACD RELOCATION BIAS 

;ACD DISPATCH TABLE POINTER 
;ACD FUNCTION MASK 

;ACD IDENTIFICATION NUMBER 
;RESERVED 

;ACD LINK WORD 

;ACD ACCESS COUNT 

;ACD STATUS BYTE 


;LENGTH OF PROTOTYPE ACB 


;FULL ACB OVERLAPS PROTOTYPE ACB 

;ACD INTERRUPT BUFFER RELOCATION BIAS 
;ACD INTERRUPT BUFFER ADDRESS 

;ACD INTERRUPT BUFFER LENGTH 

;ACD SYSTEM STATE BUFFER RELOCATION BIAS 
:ACD SYSTEM STATE BUFFER ADDRESS 

;ACD SYSTEM STATE BUFFER LENGTH 

;ACD I/O STATUS 

;RESERVED FOR USE BY THE ACD 


;LENGTH OF FULL ACB 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


i 
7 DEFINE THE FLAG VALUES IN THE OFFSET U.AFLG 


° 
c 


UA. ACC=1 7ACCEPT THIS CHARACTER 

UA. PRO=2 ;PROCESS THIS CHARACTER 

UA. ECH=4 ;ECHO THIS CHARACTER 

UA. TYP=10 ;FORCE THIS CHARACTER INTO TYPEAHEAD 
UA.SPE=20 ;THIS CHARACTER HAS A SPECIAL ECHO 

UA. PUT=40. 7PUT THIS CHARACTER IN THE INPUT BUFFER 
UA. CAL=100 ;CALL THE ACD BACK AFTER THE TRANSFER 
UA. COM=200 ;COMPLETE THE INPUT REQUEST 

UA. ALL=400 ;ALLOW PROCESSING OF THIS I/O REQUEST 
UA. TRA=1000 ; TRANSFER CHARS. WHEN I/O COMPLETES 


000000 A.ACCE: .BLKW 
000002 A.DEQU: .BLKW 
000004 A.POWE: .BLKW 
000006 A.INPU: .BLKW 
000010 A.OUTP: .BLKW 
000012 A.CONN: .BLKW 
000014 A.DISC: .BLKW 
000016 A.RECE: .BLKW 
000020 A.PROC: .BLKW 
000022 A.CALL: .BLKW 


71/0 REQUEST ACCEPTANCE ENTRY POINT 

71/0 REQUEST DEQUEUE ENTRY POINT 

7POWER FAILURE ENTRY POINT 

7 INPUT COMPLETION ENTRY POINT 

;OUTPUT COMPLETION ENTRY POINT 
;CONNECTION ENTRY POINT 

;DISCONNECTION ENTRY POINT 

;INPUT CHARACTER RECEPTION ENTRY POINT 

; INPUT CHARACTER PROCESSING ENTRY POINT 
;CALL ACD BACK AFTER TRANSFER ENTRY POINT 


PRP EEE ee PE 


DEFINE THE STATUS BITS IN A.STA OF THE PROTOTYPE ACB 


oe 58 Ne 


a 
AS. DEL=1 7ACD IS MARKED FOR DELETE 
AS. DIS=2 ;ACD IS DISABLED 


-PSECT 


177772 
177773 
177774 
177776 
000000 
000004 
000005 
000006 
000007 
000010 
000011 
000012 
000014 
000016 
000026 
000020 
000022 
000024 


me ee Ne Ne 


it eT ee TD 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


SCBDF$ 


SCBDF$ ,,SYSDEF 


STATUS CONTROL BLOCK 


THE STATUS CONTROL BLOCK (SCB) DEFINES THE STATUS OF A DEVICE 
CONTROLLER. THERE IS ONE SCB FOR EACH CONTROLLER IN A SYSTEM. 
THE SCB IS POINTED TO BY UNIT CONTROL BLOCKS. TO EXPAND ON THE 
TELETYPE EXAMPLE ABOVE, EACH TELETYPE INTERFACED VIA A DL11-A 
WOULD HAVE A SCB SINCE EACH DL11-A IS AN INDEPENDENT INTERFACE 
UNIT. THE TELETYPES INTERFACED VIA THE DH11 WOULD ALSO EACH HAVE 
AN SCB SINCE THE DH11 IS A SINGLE CONTROLLER BUT MULTIPLEXES MANY 
UNITS IN PARALLEL. 


- ASECT 
~=177772 
S.RCNT: .BLKB 1 ;NUMBER OF REGISTERS TO COPY ON ERROR 
S.ROFF: .BLKB 1 ;OFFSET TO FIRST DEVICE REGISTER 
S.BMSV: .BLRKW 1 ;SAVED I/O ACTIVE BITMAP AND POINTER TO EMB 
S.BMSK: .~BLKW 1 ;DEVICE I/O ACTIVE BIT MASK 
S.LHD: .BLKW 2 ;CONTROLLER I/O QUEUE LISTHEAD 
S.PRI: .BLKB 1 ;DEVICE PRIORITY 
S.VCT: .BLKB 1 ; INTERRUPT VECTOR ADDRESS /4 
S.CTM: .BLKB L ;CURRENT TIMEOUT COUNT 
S.ITM: .BLKB 1 ; INITIAL TIMEOUT COUNT 
S.CON: .BLKB 1 ;CONTROLLER INDEX 
S.STS: .BLKB 1 ;CONTROLLER STATUS (0=IDLE, 1=BUSY) 
S.CSR: .BLKW 1 ;ADDRESS OF CONTROL STATUS REGISTER 
S.PKT: .BLKW 1 ;ADDRESS OF CURRENT I/O PACKET 
S.FRK: .BLKW 1 7;FORK BLOCK LINK WORD 
S.DMCS: ;DM11-BB CSR FOR FDX TTDRV 

- BLKW Bi ;FORK-PC 

. BLKW 1 7FORK-R5 

- BLKW Al ;FORK-R4 


Ss. 
S.MPR: .BLKW 


S. 
Ss. 


.IF NB SYSDEF 
.IF DF LSSDRV & MSSMGE 
-BLKEW 1 ;FORK-DRIVER RELOCATION BASE 
-ENDC ;LS$DRV & MSSMGE 
CCB: :MIXED MASSBUS CHANNEL CONTROL BLOCK 


711/70 EXTENDED MEMORY UNIBUS DEVICE C-BLOCK 


- BLKW ;BUFFER WORD 


PRO O 


UMHD: .BLKW ;LIST HEAD FOR UMR ASSIGNMENT BLOCK (S) 
UMCT: .BLKW ;COUNT OF AVAILABLE UMR ASSIGNMENT BLOCK (S) 
-IFF 
~PSECT 


000000 
000002 
000004 
000006 
000010 
000011 
000012 


000014 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


; 
7 STATUS CONTROL BLOCK PRIORITY BYTE CONDITION CODE STATUS BIT 
; DEFINITIONS 


‘ 

SP. EIP=1 ;ERROR IN PROGRESS (1=YES) 

SP. ENB=2 7ERROR LOGGING ENABLED (0=YES) 
SP.LOG=4 ;ERROR LOGGING AVAILABLE (1=YES) 
5 PARE=10 ;SPARE BIT 


MAPPING ASSIGNMENT BLOCK (FOR UNIBUS MAPPING REGISTER ASSIGNMENT) 


me Me we 


- ASECT 
-=0 
M.LNK: .BLKW 1 7LINK WORD 
M.UMRA: .~BLKW 1 ;ADDRESS OF FIRST ASSIGNED UMR 
M.UMRN: .BLKW 1 ;NUMBER OF UMR'S ASSIGNED * 4 
M.UMVL: .BLKW a ;LOW 16 BITS MAPPED BY 1ST ASSIGNED UMR 
M.UMVH: .BLKB 1 ;HIGH 2 BITS MAPPED IN BITS 4 AND 5 
M.BFVH: .BLKB 1 ;HIGH 6 BITS OF PHYSICAL BUFFER ADDRESS 
M.BFVL: .BLKW 1 ;LOW 16 BITS OF PHYSICAL BUFFER ADDRESS 
M.LGTH=. ;LENGTH OF MAPPING ASSIGNMENT BLOCK 


-ENDC ;SYSDEF 


-PSECT 


000000 
000002 
000003 
000004 
000006 
000012 
000016 
000022 
000026 
000030 
000032 
000034 
000036 
000040 
000041 
000044 
000046 
000050 
000052 
000054 
000056 
000057 
000060 


me Me Ne Se Ne 


-=0 
T.LNK: 
T.PRI: 
T.IOC: 
T.CPCB: 
T.NAM: 
T.RCVL: 
T.ASTL: 
T.EFLG: 
T.UCB: 
T.TCBL: 
T. STAT: 
T.ST2: 
T.ST3: 
T.DPRI: 
T.LBN: 
T.LDV: 
T. PCB: 
T.MXSZ: 
T.ACTL: 
T.SAST: 


T.TIO: 
T.TKSZ: 


S$$=. 
T.ATT: 
T.OFF: 


T.SRCT: 
T.RRFL: 


-=$$5 
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TCBDFS- 


~ASECT 


. BLEW 
. BLKB 
. BLKB 
.- BLKW 
- BLKW 
~BLKW 
. BLKW 
. BLEW 
. BLKW 
»BLKW 
. BLEW 
. BLKW 
. BLKW 
.BLKB 
.» BLKB 
.- BLKW 
- BLEW 
. BLKW 
- BLKW 
. BLKW 
- BLKB 
. BLKB 
~BLKW 


. BLRW 
. BLKW 


. BLKB 
. BLKB 
. BLKW 


7 ,OYSDEF 


TASK CONTROL BLOCK 


PEPE PEP RPE PW HPP PEP REP ENNNNP PEE 


rN 


1 
1 
2 


.IF NDF PSSLAS 


. ENDC 


;PSSLAS 


TCBDF$ 


TASK CONTROL BLOCK OFFSET AND STATUS DEFINITIONS 


;UTILITY LINK WORD 

;TASK PRIORITY 

;1/O PENDING COUNT 

:POINTER TO CHECKPOINT PCB 

;TASK NAME IN RAD50 

;RECEIVE QUEUE LISTHEAD 

;AST QUEUE LISTHEAD 

;TASK LOCAL EVENT FLAGS 1-32 

;UCB ADDRESS FOR PSEUDO DEVICE 'TI' 
;TASK LIST THREAD WORD 

;FIRST STATUS WORD (BLOCKING BITS) 
;SECOND STATUS WORD (STATE BITS) 
;THIRD STATUS WORD (ATTRIBUTE BITS) 
;TASK'S DEFAULT PRIORITY 

;LBN OF TASK LOAD IMAGE 

;UCB ADDRESS OF LOAD DEVICE 

;PCB ADDRESS OF TASK PARTITION 
;MAXIMUM SIZE OF TASK IMAGE (MAPPED ONLY) 
;ADDRESS OF NEXT TASK IN ACTIVE LIST 
;SPECIFIED AST LISTHEAD 

;UNUSED BYTE 

;BUFFERED 1/0 COUNT 

:TASK SIZE (FROM LSBLDZ IN LABEL BLK) IN: 
UNMAPPED SYSTEMS - BYTES 

MAPPED SYSTEMS - 32 WORD BLOCKS 
:TASK SIZE (FROM LSBMXZ IN LABEL BLK) 
:FOR RSX11S SYSTEMS ONLY 

MAPPED SYSTEMS - 32 WORD BLOCKS 
UNMAPPED SYSTEMS - BYTES 


me Ne 


° 
‘ 
. 
a 


}MARK START OF PLAS AREA 

sATTACHMENT DESCRIPTOR LISTHEAD 

;OFFSET TO TASK IMAGE IN PARTITION 

;IF ASSHDR IS DEFINED, THIS WORD ALSO 
;INCLUDES THE LENGTH OF THE ALTERNATE 
;HEADER REFRESH AREA STORED IN T. HDLN 
;RESERVED 

;SREF WITH EFN COUNT IN ALL RECEIVE QUEUES 
;RECEIVE BY REFERENCE LISTHEAD 


;POINT TO START OF PLAS AREA 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


-IF NB SYSDEF 


$$$=. 
T.OCBH: .BLKW 2 
T.RDCT: .BLKW l 


.IF NDF PSSOFF 
2=S8S 
-ENDC ;PSSOFF 


$S$=. 
T.EFLM: .BLKW 2 


.IF NDF SSSTOP 
-=5$S 
-ENDC ;SSSTOP 


SS$=. 
T.HDLN: .BLKB I 
-IF NDF ASSHDR 


-=S$$ 
-ENDC ;ASSHDR 


$S$=. 
T.GGF: .BLKB 1 


-IF NDF GSSEFN 


-=SS$ 
-ENDC ;GSSEFN 
. EVEN 

T. LGTH=. 

T, EXT=0 
.IFF 


. 
a 
. 
f 
. 
e 
° 
’ 


c 
TS.EXE=100000 
TS.RDN=40000 
TS.MSG=20000 
TS.NRP=10000 
TS. RUN=4000 
TS.HLD=2000 
TS. STP=1000 
TS. OUT=400 
TS.CKP=200 
TS.CKR=100 


7MARK START OF PARENT OFFSPRING TASKING AREA 
;OFFSPRING CONTROL BLOCK LISTHEAD 
;OUTSTANDING OFFSPRING COUNT 


;POINT TO START OF PARENT OFFSPRING AREA 


;MARK START OF EVENT FLAG MASK AREA 
;EVENT FLAG MASK WORD 
;EVENT FLAG MASK ADDRESS 

& TSSBUF 


;POINT TO START OF EVENT FLAG MASK AREA 
& TSSBUF 


;TASK HEADER LENGTH IN 32-WORD BLOCKS 


:NOT SUPPORTED IF NDF 


;GROUP GLOBAL USE COUNT FOR TASK 


RSSSND 


RSSSND 


;LENGTH OF TASK CONTROL BLOCK 
;LENGTH OF TCB EXTENSION 


TASK STATUS DEFINITIONS 


FIRST STATUS WORD (BLOCKING BITS) 


;TASK NOT IN EXECUTION (1=YES) 

71/0 RUN DOWN IN PROGRESS (1=YES) 

;ABORT MESSAGE BEING OUTPUT (1=YES) 

;TASK MAPPED TO NONRESIDENT PARTITION (1=YES) 
;TASK IS RUNNING ON ANOTHER PROCESSOR (1=YES) 
;TASK HALF-LOADED BY TASK LOADER 

;TASK EXTERNALLY BLOCKED VIA CLI COMMAND 
;TASK IS OUT OF MEMORY (1=YES) 

;TASK IS BEING CHECKPOINTED (1=YES) 

;TASK CHECKPOINT REQUESTED (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


. 
’ 
. 
e 
* 
i 

T 


. 
a 
. 
, 


a 
T2.AST=100000 
T2.DST=40000 
T2.CHK=20000 
T2.CKD=10000 
T2. SEF=4000 
T2.FXD=2000 
T2. REX=1000 
T2.CAF=400 
T2. HLT=200 
T2.ABO=100 
T2.STP=40 
T2.STP=20 
T2.SPN=10 
T2.,SPN=4 
T2,.WFR=2 
T2.WFR=1 


TASK BLOCKING STATUS MASK 


S.BLK=TS.CKP!TS.CKR!TS. EXE! TS.MSG!TS.NRP!ITS. OUT!TS. RDN! TS.STP 


SECOND STATUS WORD (STATE BITS) 


;AST IN PROGRESS (1=YES) 

;AST RECOGNITION DISABLED (1=YES) 

7TASK NOT CHECKPOINTABLE (1=YES) 
;CHECKPOINTING DISABLED (1=YES) 

;TASK STOPPED FOR EVENT FLAGS (1=YES) 
;TASK FIXED IN MEMORY (1=YES)} 

7ABORT AST EFFECTED OR IN PROGRESS (1=YES) 
7DYN CHECKPOINT SPACE ALLOCATION FAILURE 
;TASK IS BEING HALTED (1=YES) 

;TASK MARKED FOR ABORT (1=YES) 

;SAVED T2.STP ON AST IN PROGRESS 

7TASK STOPPED (1=YES) 

;SAVED T2.SPN ON AST IN PROGRESS 

;TASK SUSPENDED (1=YES) 

7;SAVED T2.WFR ON AST IN PROGRESS 

;TASK IN WAITFOR STATE (1=YES) 


i 
7 THIRD STATUS WORD (ATTRIBUTE BITS) 


fd 

T3, ACP=100000 
T3. PMD=40000 
T3. REM=20000 
T3, PRV=10000 
T3,MCR=4000 
T3.SLV=2000 
T3.CLI=1000 
T3.RST=400 
T3.NSD=200 
T3.CAL=100 
T3. ROV=40 
T3.NET=20 
T3.GFL=10 


»~ENDC ;SYSDEF 


- PSECT 


7; ANCILLARY CONTROL PROCESSOR (1=YES) 
7DUMP TASK ON SYNCHRONOUS ABORT (0=YES) 
7REMOVE TASK ON EXIT (1=YES) 

TASK IS PRIVILEGED (1=YES) 


7;TASK REQUESTED AS EXTERNAL MCR FUNCTION (1=YES) 


;TASK IS A SLAVE TASK (1=YES) 
;TASK IS A COMMAND LINE INTERPRETER (1=YES) 
; TASK IS RESTRICTED (1=YES) 

;TASK DOES NOT ALLOW SEND DATA 

;TASK HAS CHECKPOINT SPACE IN TASK IMAGE 
;TASK HAS RESIDENT OVERLAYS 

;NETWORK PROTOCOL LEVEL 

7TASK HAS ITS GRP GBL EVENT FLAGS LOCKED 
7RESERVED FOR FUTURE USE 

;RESERVED FOR USE BY SOFTWARE SERVICES 
RESERVED FOR FUTURE USE 
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UCBDF$ 


177772 
177772 
177774 
177776 
000000 
000002 
000004 
000005 
000006 
000007 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 


UCBDFS$ 


re YT al a il aD 


SPECIFIC DCB. 


r,TTIDEF,SYSDEF 


UNIT CONTROL BLOCK 


SYS DEF 


ESSDVC 


~IF DF MSSMUP 


» ASECT 

IF NB 

IF DF 
-=177766 

IFF 
-=177770 

» ENDC 
U.IOC: .BLKW 
U.ERSL: .BLKB 
U.ERHL: .BLKB 
U.ERSC: .BLKB 
U.ERHC: .BLKB 

- ENDC 

. ENDC 
~=177772 
U.MUP: 
U.CLI: - BLKW 
U.LUIC: .~BLKW 
U. OWN: . BLKW 
U.DCB: - BLKW 
U.RED: .BLKW 
U.CTL: .BLKB 
U.STS: ~ BLKB 
U.UNIT: .~BLKB 
U.ST2: . BLKB 
U.CW1l: .BLKW 
U.CW2: . BLKW 
U.CW3: .BLKW 
U.CW4: - BLKW 
U.SCB: - BLKW 
U.ATT: - BLKW 
U.BUF: « BLKW 

- BLEW 
U.CNT: » BLKW 


MSSMUP 


~ 


PRED 


;ESSDVC 


7SYS DEF 


ee 


THE UNIT CONTROL BLOCK (UCB) DEFINES THE STATUS OF AN INDIVIDUAL 
DEVICE UNIT AND IS THE CONTROL BLOCK THAT IS POINTED TO BY THE 
FIRST WORD OF AN ASSIGNED LUN. THERE IS ONE UCB FOR EACH DEVICE 
UNIT OF EACH DCB. THE UCB'S ASSOCIATED WITH A PARTICULAR DCB ARE 
CONTIGUOUS IN MEMORY AND ARE POINTED TO BY THE DCB. 
VARIABLE LENGTH BETWEEN DCB'S BUT ARE OF THE SAME LENGTH FOR A 
TO FINISH THE TELETYPE EXAMPLE ABOVE, 
BOTH INTERFACES WOULD HAVE A UCB. 


UCB'S ARE 


EACH UNIT ON 


71S U.OWN THERE? 


71/0 COUNT SINCE MOUNT 
;SOFT ERROR LIMIT 
7;HARD ERROR LIMIT 
;SOFT ERROR COUNT 
;HARD ERROR COUNT 


(ERROR LOG DEVS ONLY) 


:MULTIUSER PROTECTION FLAG WORD 

;TCB OF COMMAND LINE INTERPRETER 

;LOGIN UIC - MULTI USER SYSTEMS ONLY 
;OWNING TERMINAL - MULTI USER SYSTEMS ONLY 
:BACK POINTER TO DCB 

;POINTER TO REDIRECT UNIT UCB 

;CONTROL PROCESSING FLAGS 

;UNIT STATUS 

;PHYSICAL UNIT NUMBER 

;UNIT STATUS EXTENSION 

;FIRST DEVICE CHARACTERISTICS WORD 
;SECOND DEVICE CHARACTERISTICS WORD 
;THIRD DEVICE CHARACTERISTICS WORD 
;FOURTH DEVICE CHARACTERISTICS WORD 
;POINTER TO SCB 

;TCB ADDRESS OF ATTACHED TASK 
;RELOCATION BIAS OF CURRENT I/O REQUEST 
;BUFFER ADDRESS OF CURRENT I/O REQUEST 
;BYTE COUNT OF CURRENT I/O REQUEST 


C-42 


000032 
000034 
000032 
000032 
000034 


000036 
000036 
000040 
000042 


000036 
000040 
000044 


000050 
000052 
000054 
000060 
000070 
000074 
000076 
000100 
000102 
000104 
000110 
000112 
000113 


000114 
000120 


000024 
000026 
000034 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


U.ACP=U.CNT+2 ;ADDRESS OF TCB OF MOUNTED ACP 

U. VCB=U.CNT+4 ;ADDRESS OF VOLUME CONTROL BLOCK 
U.CBF=U.CNT+2 ;CONTROL BUFFER RELOCATION AND ADDRESS 
U. KCSR=U.CNT+2 7;CSR ADDRESS OF KMC-11 

U. KCS6=U. KCSR+2 7CSR+6 OF KMC-11 

i 

; MAGTAPE DRIVER DEFINITIONS 

, 

U.SPC=U.CNT+6 ;SPACING COUNT 

U.SUB=U.CNT+6 ;SUBCONTROLLER, PHYSICAL UNIT #. 

U. FNUM=U.CNT+10 ;FORMATTER NUMBER 

U.FCDE=U.CNT+12 ;FUNCTION CODE AND INDEX 

; MSCP DISK DRIVER UCB OFFSETS 

f 

U.UTMO=U. VCB+2 ;UNIT COMMAND TIME OUT 

U. LHD=U. VCB+4 ;UNIT OUTSTANDING I/O PACKET LISTHEAD 
U.BPKT=U. VCB+10 ;UNIT BAD BLOCK PACKET WAITING LIST 

7 

; CHARACTERISTICS OBTAINED FROM "GET UNIT STATUS" END PACKETS 
a 

U.MLUN=U. VCB+14 ;MULTI-UNIT CODE 

U.UNFL=U. VCB+16 ;UNIT FLAGS 

U.HSTI=U. VCB+20 ;HOST IDENTIFIER 

U.UNTI=U.VCB+24 ;UNIT IDENTIFIER 

U.MEDI=U. VCB+34 ;MEDIA IDENTIFIER 

U. SHUN=U. VCB+40 ;SHADOW UNIT 

U.SHST=U. VCB+42 ;SHADOW UNIT STATUS 

U. TRCK=U. VCB+44 ;UNIT TRACK SIZE 

U.GRP=U. VCB+46 ;UNIT GROUP SIZE 

U.CYL=U. VCB+50 ;UNIT CYLINDER SIZE 

U.RCTS=U. VCB+54 ;UNIT RCT TABLE SIZE 

U. RBNS=U. VCB+56 ;UNIT RBN 'S / TRACK 

U.RCTC=U. VCB+57 ;UNIT RCT COPIES 

? 

; CHARACTERISTICS OBTAINED FROM "ONLINE" OR "SET UNIT CHARACTERISTICS" 
7 END PACKETS 

v 

U.UNSZ=U. VCB+60 ; UNIT SIZE 

U. VSER=U. VCB+64 ; VOLUME SERIAL NUMBER 


7 
; TERMINAL DRIVER DEFINITIONS 
; 


=U.BUF 
U.TUX: .BLKW 
U.TSTA: .BLKW 
U.TTAB: .BLKw 


#POINTER TO UCB EXTENSION (UCBX) 

;STATUS TRIPLE-WORD 

;IF O: U.TTAB+1 IS SINGLE-CHARACTER TYPE-AHEAD 

; BUFFER, CURRENTLY EMPTY 

;IF ODD: U.TTAB+1 IS SINGLE-CHARACTER 

; TYPE-AHEAD BUFFER AND HOLDS A 
CHARACTER 

IF NON-O0 AND EVEN: POINTER TO MULTI-CHARACTER 
TYPE-AHEAD BUFFER 


HWP 


me Ne Ne OS 


000036 
000037 
000040 
000042 
000043 
000044 
000046 
000047 
000050 
000052 
000054 
000056 


000030 
000032 
000036 


U.TLPP: .~BLKB 
U.TFRO: .BLKB 
U.TFLK: .~BLKW 
U.TCHP: .BLKB 
» BLKB 
- BLKW 
U.TTYP: .BLKB 
U.TMTI: .BLKB 
U.CTYP: .BLKW 
. BLKW 
U.AFLG: .~BLKW 
U.ADMA: .BLKW 


U.TCVP: 
U.UIC: 


U.ACB: 
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lee 


;LINES PER PAGE 

;FORK REQUEST BYTE 

;FORK LIST LINK WORD 

;CURRENT HORIZONTAL POSITION 
;CURRENT VERTICAL POSITION 

;TERMINAL UIC 

; TERMINAL TYPE 

;MODEM TIMER 

;CONTROLLER TYPE 

;ANCILLARY CONTROL DRIVER BLOCK ADDR 
;ANCILLARY CONTROL DRIVER FLAGS WORD 
;ANCILLARY CONTROL DRIVER DMA BUFFER 


i 
; CONSOLE DRIVER DEFINITIONS 
; 


=U.CNT 


U.CTCB: .BLKW 1 


U.COTO: .BLKW 


U.RED2: .BLKW 1 


o me we 


$1. RST=1 


DEFINE BITS IN STATUS 


;ADDRESS OF CONSOLE LOGGER TCB 
71/O PACKET LIST QUEUE 
;REDIRECT UCB ADDRESS 


WORD 1 (U.TSTA) 


;READ WITH SPECIAL TERMINATORS IN PROGRESS 
S1. RUB=2 ;RUBOUT SEQUENCE IN PROGRESS (NON-SCOPE) 
$1. ESC=4 ;ESCAPE SEQUENCE IN PROGRESS 
S1,. RAL=10 ;READ ALL IN PROGRESS 
S1. RNE=20 ;ECHO SUPPRESSED 
$1.CTO=40 ;OUTPUT STOPPED BY CTRL-O 
$1. OBY=100 ; OUTPUT BUSY 
S1.IBY=200 ; INPUT BUSY 


§1.BEL=400 


$1. DPR=1000 
$1. DEC=2000 
S1.DST=4000 
$1.CTS=10000 
$1.USI=20000 


S1.OBF=40000 
$1. IBF=100000 


i 
; DEFINE BITS IN STATUS 


$2.BRQ=20 
$2.SRQ=40 


$2. ORQ=100 
$2, IRQ=200 
$2, HFL=3 400 
$2. VFL=4000 
$2. HHT=10000 
$2. HFF=20000 
$2. FLF=40000 
$2, FDX=100000 


;BELL PENDING 

;DEFER PROCESSING OF CHAR. IN U.TECB 
:;DEFER ECHO OF CHAR. IN U.TECB 

; INPUT PROCESSING DISABLED 

;OUTPUT STOPPED BY CTRL-S 

; UNSOLICITED INPUT IN PROGRESS 

;BIT 14 RESERVED FOR NON-BUFFERED OUT PUT 
:BUFFERED OUTPUT IN PROGRESS 

;BUFFERED INPUT IN PROGRESS 


WORD 2 (U.TSTA+2) 


;WRAP-AROUND (AUTOMATIC CR-LF) REQUIRED 
;CONTEXT FOR WRAP-AROUND 

;LOW BIT IN S2.WRA BIT PATTERN 
;TRAILING CR REQUIRED ON OUTPUT 

; BREAK-THROUGH-WRITE REQUEST IN QUE UE 
:;SPECIAL REQUEST IN QUEUE 

;(IO.ATT, IO.DET, SF.SMC) 

;OUTPUT REQUEST IN QUEUE (MUST = $1. 0OBY) 
;INPUT REQUEST IN QUEUE (MUST = S1.IBY) 
;HORIZONTAL FILL REQUIREMENT 

; VERTICAL FILL REQUIREMENT 

:HARDWARE HORIZONTAL TAB PRESENT 
;HARDWARE FORM-FEED PRESENT 

;FORCE LINE FEED BEFORE NEXT ECHO 

;LINE IS IN FULL DUPLEX MODE 
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; 
; 
: 
S 


3. RAL=10 


S3.RPO=20 
S3.WES=40 
$3. TAB=100 
$3. 8BC=200 
$3. RCU=400 
$3.ABD=1000. 
$3. ABP=2000 
$3.WAL=4000 
$3. VER=10000 


$3.BCC=20000 


$3. DA0=40000 


$3. PCU=100000 


-PSECT 


oe Ne Ne Ne 


, 

DV. REC=1 

DV. CCL=2 

DV. TTY=4 

DV. DIR=10 
DV. SDI=20 
DV. SQD=40 
DV.MSD=100 
DV. UMD=200 
DV.MBC=400 
DV. EXT=400 
DV. SWL=1000 
DV. IS P=2000 
DV. OS P=4000 
DV. PSE=10000 
DV. COM=20000 
DV. F11=40000 


DEFINE BITS IN STATUS 


WORD 3 (U.TSTA+4) 


; TERMINAL IS IN READ-PASS-ALL MODE 
; ($3.RAL MUST = $1. RAL) 

;READ W/PROMPT OUTPUT IN PROGRESS 

;TASK WANTS ESCAPE SEQUENCES 

;TYPE-AHEAD BUFFER ALLOCATION REQUESTED 
;PASS 8 BITS ON INPUT 

;RESTORE CURSOR (MUST = TF.RCU*400) 
;AUTO-BAUD SPEED DETECTION ENABLED 
;AUTO-BAUD SPEED DETECTION IN PROGRESS 
;WRITE-PASS-ALL (MUST = TF.WAL*400) 
;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS PARITY ERROR 

;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS FRAMING ERROR 

;LAST CHAR, IN TYPE-AHEAD BUFFER 

;HAS DATA OVERRUN ERROR 

;NOTE - THE 3 BITS ABOVE MUST CORRESPOND 
;TO THE RESPECTIVE ERROR FLAGS IN THE 
;HARDWARE RECEIVE BUFFER 

;POSITION CURSOR (MUST = TF.PCU*400) 


DEVICE TABLE STATUS DEFINITIONS 


DEVICE CHARACTERISTICS WORD 1 (U.CW1) DEVICE TYPE DEFINITION BITS. 


;RECORD ORIENTED DEVICE (1=YES) 

;CARRIAGE CONTROL DEVICE (1=YES) 

TERMINAL DEVICE (1=YES) 

;FILE STRUCTURED DEVICE (1=YES) 

;SINGLE DIRECTORY DEVICE (1=YES) 
;SEQUENTIAL DEVICE (1=YES) 

;MASS STORAGE DEVICE (1=YES) 

;USER MODE DIAGNOSTICS SUPPORTED (1=YES) 
;DEVICE IS ON MASSBUS CONTROLLER (1=YES) 
;DEVICE ON EXTENDED ADDRESSING CONTROLLER 
;UNIT SOFTWARE WRITE LOCKED (1=YES) 

; INPUT SPOOLED DEVICE (1=YES) 

;OUTPUT SPOOLED DEVICE (1=YES) 

;PSEUDO DEVICE (1=YES) 

;DEVICE IS MOUNTABLE AS COM CHANNEL (1=YES) 
;DEVICE IS MOUNTABLE AS F1l DEVICE (1=YES) 


DV.MNT=100000 ;DEVICE IS MOUNTABLE (1=YES) 


; TERMINAL DEPENDENT CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


U2. DH1=100000 ;UNIT IS A MULTIPLEXER (1=YES) 


U2.DJ1=40000 
U2. RMT=20000 
U2. HFF=10000 
U2. L8S=10000 
U2. NEC=4000 
U2. CRT=2000 
U2. ESC=1000 
U2. LOG=400 

U2. SLV=200 

U2.DZ1=100 


;UNIT IS A DJ11l (1=YES) 

;UNIT IS REMOTE (1=YES) 

;UNIT HANDLES HARDWARE FORM FEEDS (1=YES) 
;OLD NAME FOR U2.HFF 

;DON'T ECHO SOLICITED INPUT (1=YES) 

;UNIT IS A CRT (1=YES) 

;UNIT GENERATES ESCAPE SEQUENCES (1=YES) 
;USER LOGGED ON TERMINAL (0=YES) 

;UNIT IS A SLAVE TERMINAL (1=YES) 

:;UNIT IS A DZ11l (1=YES) 
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U2. HLD=40 
U2.AT.=20 
U2. PRV=10 
U2. L35=4 
U2.scS=4 
U2. VT5=2 
U2. LWC=1 


eo «ee Ne 


, 

UM.OVR=1 
UM. CLI=36 
UM. DSB=200 
UM.NBR=400 


U2. R04=100000 


2. 7CH=10000 


3.UPC=20000 


° 
f 
. 
' 


c 

UC. ALG=200 
UC.NPR=100 
UC. QUE=40 
UC. PWF=20 
UC. ATT=10 
UC. KIL=4 
UC. LGH=3 


owe Ne 


a 

US.BSY=200 
US.MNT=100 
US. FOR=40 
US.MDM=20 
US. PWF=10 


CARD READER DEPENDENT 


we Ne Me 


US. ABO=1 
US.MDE=2 


;TERMINAL IS IN HOLD SCREEN MODE (1=YES) 
MCR COMMAND AT. BEING PROCESSED (1=YES) 
;UNIT IS A PRIVILEGED TERMINAL (1=YES) 

sUNIT IS A LA30S TERMINAL (1=YES) 

7SCS-11 COMMAND TERMINAL (1=YES) 

;UNIT IS A VTO5B TERMINAL (1=YES) 

7;LOWER CASE TO UPPER CASE CONVERSION (0=YES) 


BIT DEFINITIONS FOR U.MUP (SYSTEMS WITH ALTERNATE CLI SUPPORT ONLY) 


;OVERRIDE CLI INDICATOR 

3;CLI INDICATOR BITS 

7; TERMINAL DISABLED SINCE CLI ELIMINATED 
7NO BROADCAST 


RH11-RS03/RS04 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


;UNIT IS A RSO4 (1=YES) 


RH11-TU16 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


;UNIT IS A 7 CHANNEL DRIVE (1=YES) 


TERMINAL DEPENDENT CHARACTERISTICS WORD 3 (U.CW3) BIT DEFINITIONS 


;UPCASE OUTPUT FLAG 


UNIT CONTROL PROCESSING FLAG DEFINITIONS 


;BYTE ALIGNMENT ALLOWED (1=NO) 

;DEVICE IS AN NPR DEVICE (1=YES) 

7CALL DRIVER BEFORE QUEUING (1=YES) 
7;CALL DRIVER AT POWERFAIL ALWAYS (1=YES) 
7;CALL DRIVER ON ATTACH/DETACH (1=YES) 
;CALL DRIVER AT I/O KILL ALWAYS (1=YES) 
7; TRANSFER LENGTH MASK BITS 


UNIT STATUS BIT DEFINITIONS 


; UNIT 
; UNIT 


IS BUSY (1=YES) 
IS MOUNTED (0=YES) 

;UNIT IS MOUNTED AS FOREIGN VOLUME (1=YES) 
;UNIT IS MARKED FOR DISMOUNT (1=YES) 
;POWERFAIL OCCURRED (1=YES) 


UNIT STATUS BIT DEFINITIONS 


;UNIT IS MARKED FOR ABORT IF NOT READY (1=YES) 
;UNIT IS IN 029 TRANSLATION NODE (1=YES) 
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i 
; FILES-11 DEPENDENT UNIT STATUS BITS 


a’ 

US .WCK=10 
US. SPU=2 
US. VWV=1 


S.KPF=1 


we Se Me 


-IF NB TTDEF 


-IF DF TSSCPW 


US. CRW=4 
US. DSB=2 
US.OIU=1 


-IFF 
US. DSB=10 
US.CRW=4 
US. ECH=2 
US.OUT=1 

- ENDC 


- ENDC 


2 38 we 


, 
US. FRK=2 
US. SHR=1 


ome Ne 


US. LAB=4 
US.BSP=2 


;TSSCPW 


#TSSC PW 


;TTDEF 


;WRITE CHECK ENABLED (1=YES) 


;UNIT IS SPINNING UP (1=YES) 
; VOLUME VALID IS SET (1=YES) 


KMC-1]1-LP DEPDENDENT UNIT STATUS BITS 


7KMC-11 POWERFAIL INTERLOCK 


TERMINAL DEPENDENT UNIT STATUS BIT DEFINITIONS 


;UNIT IS WAITING FOR CARRIER (1=YES) 
;UNIT IS DISABLED (1=YES) 
;OUTPUT INTERRUPT IS UNEXPECTED ON UNIT (1=YES) 


;UNIT IS DISABLED (1=YES) 

;UNIT IS WAITING FOR CARRIER (1=YES) 

;UNIT HAS ECHO IN PROGRESS (1=YES) 

;UNIT IS EXPECTING OUTPUT INTERRUPT (1=YES) 


LPS11 DEPENDENT UNIT STATUS BIT DEFINITIONS 


7FORK IN PROGRESS (1=YES) 
;SHAREABLE FUNCTION IN PROGRESS (0=YES) 


MAGTAPE DEPENDANT UNIT STATUS BITS 


;UNIT HAS LABELED TAPE ON IT (1=YES) 
; INTERNAL BACKSPACE IN PROGRESS (1=YES) 
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; UNIT STATUS EXTENSION 


a 

US. OFL=1 
US. RED=2 
US. PUB=4 
US. UMD=1 


MAG TA 


eo Se Ne Me 


UD. UNS=0 
UD. 200=1 
UD. 556=2 
UD. 800=3 
UD. 160=4 
UD. 625=5 


0 


PE DENS SUPPORT 
ASSIGNMENTS PER 


(U.ST2) BIT DEFINITIONS 


;UNIT OFFLINE (1=YES) 

;UNIT REDIRECTABLE (0=YES) 

;UNIT IS PUBLIC DEVICE (1=YES) 

;UNIT ATTACHED FOR DIAGNOSTICS (1=YES) 


IDENT IN CHAR WORD 3 (U.CW3) DEFENITION 
NUMERICAL SEQUENCE 0 - 255. 


; UNSUPPORTED 

200BPI, 7 TRACK 
556BPI, 7 TRACK 
800BPI, 7 OR 9 TRACK 
;1600BPI, 9 TRACK 
;6250BPI, 9 TRACK 


me Ne Me 


APPENDIX D 


USER-WRITTEN ANCILLARY CONTROL PROCESSORS 


This chapter is intended as a guide for the user in developing an 
Ancillary Control Processor (ACP). It is not a tutorial and it is not 
a description of the logic of any DIGITAL-supplied ACP. You should be 
thoroughly familiar with the RSX-11M Guide to Writing an I/O Driver. 
This chapter provides the following information: 

e An overview of the RSX-11M I/0 system 

e Descriptions of the types of ACPs 

e The attributes of an ACP 


e A description of the flow of an input/output request, 
emphasizing the role of the ACP 


e System data structures used by the ACPs 


e Examples of an ACP and an I/O driver 


D.1 OVERVIEW OF THE RSX-11M I/O SYSTEM 


An Ancillary Control Processor (ACP) is one component of the RSX I/0 
system. The other major components are 


e File Control Services (FCS) or Record Management Services 
(RMS) 


@e QIOS directive processing in the Executive 
e Device drivers 
Figure D-l shows how an ACP fits into the overall structure. 
The philosophy and structure of the RSX-11M I/0 system are described 


in detail in Chapter 2 of this manual. OIO$ directive processing is 
described in the RSX-11M/M-PLUS Executive Reference Manual. 
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User Task 
FCS 


ZK-227-81 


Figure D-1 The RSX-11M I/O System 


D.2 TYPES OF ANCILLARY CONTROL PROCESSORS 
An Ancillary Control processor (ACP) is a task that provides extended 
functions (complex operations requiring either multiple I/O requests 
or special privileged operations) for a class of I/O devices. 
ACPs may be divided into three types: 

e Those that manage file structures, such as F11ACP and MTAACP 


e Those that manage intertask or interprocessor communication, 
such as the network ACP (NETACP) 


e Those that perform special privileged operations on behalf of 
nonprivileged user tasks. 
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Some of the purposes of a user-written ACP are: 
e To implement a foreign file system 
e To extend the capabilities of a DIGITAL-supplied device driver 
e To extend the services of the operating system 
e To implement a communications protocol 


User-written ACPs extend functionality, not performance. If your 
application is performance-oriented, you should consider writing a 
special driver rather than an ACP. 


D.2.1 ACPs Which Manage Files Structures 


DIGITAL supplies F1iACP for Files-1i disk structure and MTAACP for 
ANSI magnetic tapes. You may write an ACP to implement a foreign file 
system or tape format. Changes to the Executive, the I/O driver, or 
the data structures are not necessary if there are DIGITAL-supplied 
I/O operations that correspond to operations for the foreign format. 
The user-written ACP can use the built-in Executive Services (such as 
QIOS directive processing) without change. 


Note that a user-written ACP is necessary only to support a file 
structure other than Files-ll. To use the Files-1ll structure with a 
foreign device, you need to write a device driver, and you may need to 
modify or extend disk initialization, management, or backup utilities. 


D.2.2 ACPs Which Manage Intertask or Interprocessor Communication 


DECnet/M and DECnet/M-PLUS both contain an example of an ACP that 
manages interprocessor communications: NETACP, used for management of 
the Digital Network Architecture Communications protocol. You may 
write an ACP to manage a foreign communications protocol. 


D.2.3 ACPs Which Perform Privileged Operations for Unprivileged Tasks 


You may write an ACP to support extended capabilities for a class of 
devices (such as line printer spooling or associative name searching 
for data base devices). This requires special support in the 
Executive I/O processing, in the I/O driver, and in the associated 
data structures. This type of ACP requires a user-written I/O driver 
that contains special code to support the ACP. 


An ACP may use the I/O driver interface to extend the services of the 
operating system (as in the case of a data base management system), 
rather than to extend the services of an I/O device. 


RSX-11M contains no DIGITAL-supplied examples of the types just 
described. Both RSX-11M and RSX-11M-PLUS, however, contain COT and 
CODRV, which are used to perform console logging. The COT task 
behaves in the fashion of an ACP, in that it receives I/0 packets in 
its queue from user tasks. COT is not declared to the system as an 
ACP, though; it has no VCB or MOU interface. COT is enabled and 
disabled using MCR commands. 
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D.3 THE ATTRIBUTES OF AN ACP 


The classes of ACPs described above have the following attributes in 
common, which further define an ACP: 


e An ACP is an asynchronous privileged task. Refer to the 
RSX-11M/M-PLUS Task Builder Manual for a discussion of 
privileged task mapping and Executive access. 


@ An ACP implements a protocol (or set of services) for a class 
of devices (for example, file-structured devices or sequential 
devices). 


e An ACP functions as an extension of the Executive and 
frequently operates with Executive privilege. 


@ An ACP can be enabled or disabled for a particular device. 


e An ACP is shareable among several device drivers and units. 


D.3.1 ACP as a Task 
An ACP is a task. It has all the attributes of a task, including: 
e A stack 
e A task name 
e Priority 
e@ Scheduling by the Executive 


An ACP, in contrast to a driver, operates aS a task. While a driver 
handles interrupts, manipulates CSRs, and performs other 
device-specific operations, an ACP is not device bound and can _ take 
advantage of the services and control mechanisms available to tasks. 
ACPs can also use overlays, and can therefore be larger and have 
greater functionality than drivers. 


Because the ACP task is privileged, it has access to the Executive 
data structures and can use Executive facilities. 


Unlike other privileged tasks, an ACP has the capacity to receive I/0 
packets from other tasks by means of the QIOS$ directive. This permits 
the ACP to act as an I/O handler, which can compete with user tasks 
for system resources more equitably than an I/O driver could. Also, 
unlike an I/O driver, an ACP can perform I/0 to other devices during 
the processing of an I/O request. 


D.3.2 Class of Devices 


An ACP can easily implement functions for a class of devices because 
it communicates via the QIOS directive, which is relatively 
device-independent. (Drivers, in contrast, are written to suit the 
minute peculiarities of particular devices.) FI11ACP, for example, 
implements the Files-1l structure for all types of disks and DECtapes. 
MTAACP ‘implements ANSI magnetic tape format for all DIGITAL-supported 
9-track magnetic tape drives. 
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D.3.3 Extension of Executive 


An ACP extends the functionality of both the Executive and the device 
drivers in several ways: 


e By removing the burden of device managment (assigning space on 
a volume, locating the desired data area, and so on) from the 
programmer. 


@ By handling the manipulation of device- and protocol-related 
data. 


e By permitting a device to be treated as a logical rather than 
a physical entity. 


e By allowing a device to be shared for simultaneous access. 
Each process that accesses a device is protected from other 


processes by the ACP and its protocol. The ACP also 
synchronizes access to the physical device. 


D.3.4 Enabling Capability and Disabling Capability 
An ACP can be enabled or disabled for a given device. When enabled, 


the device is available for use in the context of the protocol 
provided by the ACP. 


D.3.5 Shareability 


An ACP is shareable among several device drivers and units. 


D.4 THE FLOW OF AN I/O REQUEST 
This section describes the system interactions of an ACP during the 
flow of an I/O request. On the assumption that you have read Section 
2.6 of this manual, only those items relevant to ACPs are treated in 
detail. The structure of this section is similar to that of Section 
2.6. 
The I/O flow proceeds as described below: 
l. (Task issues a QIOS directive] 
The Executive performs the following: 
a. First-level validity checks 
b. Redirect algorithm 
c. Additional validity checks 
2 {Executive obtains storage for and creates I/O packet] 


3. [Executive validates the function requested] 


If the function is an ACP function, the type of function 
validation depends on the type of ACP. 
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a. Standard DIGITAL-supplied ACP 


If the device is mounted with an ACP, the function 
code is validated to determine that it is an ACP 
function. The parameters are verified by code in the 
QIO processing module. The request is checked for 
proper order (for example, OPEN before CLOSE) and for 
valid buffers. The task that issues the I/O request 
must validate any additional parameter block required 
by the ACP, For some functions, an additional 
parameter buffer is allocated and filled in. 


Sometimes the I/O request can be transformed into a 
transfer function and queued to the proper driver. 
If the request cannot be queued to the driver or 
cannot be completed immediately, it is queued to the 
ACP, The request packet is inserted in the ACP's 
receive data queue and the ACP is’ unstopped or 
requested to run (depending on whether it was 
active). 


b. Nonstandard ACPs and ACPs requiring special Executive 
or driver support 


The QIOS directive processing cannot validate the ACP 
function request parameters. The I/O driver must do 
the validation. The UC.QUE bit in the driver must be 
set so that the OIO processing routine calls the 
driver directly, without queuing the I/O packet to 
the driver or to the ACP. 


The driver must perform the same functions for the 
ACP as the OQIO processing code does for standard and 
replacement ACPs. 


(Driver processing] 


If the driver calls $GTPKT and the next request in the queue 
is an ACP function request, SGTPKT will queue the request to 
the ACP and activate the ACP, 


{ACP processing] 

Obtain Work 

As soon as the ACP is activated, it attempts to remove an I/0 
request packet from its receive data queue. To do this, the 
ACP switches to system state and calls SQRMVF to obtain the 
address of the I/O packet. (Note that the ACP does not use 
the RCVDS directive to remove the packet from its receive 
queue.) When the ACP has obtained the address of the I/0 
packet, it returns to task state. 

Process I/O Request 


The ACP either completes the I/O request or translates it 
into a standard I/O driver request. The decision is based 
on: 

e Information in the data structures 


e Computation 


e Additional I/0 
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The ACP may do its own QIO requests to the driver; the ACP then 
calls SIOFIN with the I/O packet and the I/0 status. 
Alternatively, when the I/O request is translated into a driver 
request, the ACP modifies the I/O packet to put it into the 
correct form for a driver request and passes it to the driver by 
calling SDROQRQ. If the I/O request has been completed, the ACP 
calls SIOFIN with the I/O packet and the I/O status. 


For example, MTAACP always deals with the driver through QIO 
requests, and finishes I/O itself by calling S$IOFIN. 


The ACP then attempts to remove another request from its queue. 
If there are no more requests in the queue, the ACP stops itself 
by calling SSTPCT, 


D.5 SYSTEM DATA STRUCTURES 


An ACP interfaces to the system through use of system data structures 
and through calls to Executive routines. This section describes 
ACP-specific information for the various data structures. Detailed 
information on the data structures and their interrelationships is 
contained in Section 2.7 and Chapter 4 of this manual. 


The following data structures comprise the complete set for I/0 
processing: 


e Task header 
@ Window Block (WB) 
e File Control Block (FCB) 


@ SDEVHD word, the Device Control Block (DCB), and the Driver 
Dispatch Table (DDT) 


e Unit Control Block (UCB) 

@ Status Control Block (SCB) 

e@ Volume Control Block (VCB) 

e I/0 packet 
When you write an ACP, you are usually concerned only with the I/0 
packet, the DCB, the UCB, and the SCB. There are ACP-specific 


additions to and variations in the I/O packet, the DCB, and the UCB. 
The SCB is the same as that for an I/O driver. 


D.5.1 The I/O Packet 


Figure D-2 shows the layout of the 18-word I/O packet, which is 
constructed by OQIO$ directive processing. The fields in the I/0 
packet are described in detail in Section 4.1.1 of this manual. The 
following additions and variations exist for ACPs: 


I.FCN 


Contains the function code for the I/0 request. The function 
code and modifier comprise a 16-bit field. Bits 13,14, and 15 
are reserved for ACP interface use. You must not assume that 
these bits are zero. 
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If the function code field is referenced, the value should be 
masked with 160000(8) for example: 


MOV I.FCN(R1),RO ; GET FUNCTION CODE FIELD 
BIC #160000, RO : CLEAR OFF EXTRANEOUS BITS 


Although these bits are not currently in use, they should not be 
assumed to be zero in order to ensure future compatibility. If 
an I/O packet is requeued to the device driver, these bits must 
be cleared. 


I. PRM 


Contains the device-dependent parameters constructed from the 
last six words in the DPB. 


The following fields are defined for Files-1l nontransfer 
operations: 


~ASECT 

-=I.PRM 

I.FIDP: .BLKW 2 File ID address (Address double 
word format) 

Attribute block pointer (This field 
points to a buffer containing the 
attribute list and associated address 
doublewords) 

Extend control from parameter list 
Retrieval pointers desired 

Access control 

File name block pointer 


I.RWAT: .BLKW 1 


I.EXTD: .BLKW 
I.RTRV: .BLKB 
I.ACTL: .~BLKB 
I.FNBP: .~BLKW 


me Me Me te Ne Me Ne Me te Ne 


NOR Fd 


The following fields are defined for Files-1l transfer operations: 


-ASECT 
-=I.PRM 


I.RWAD: .BLKW 2 ; Transfer address doubleword 
I.RWCT: .BLRKW 1 3; Transfer count 
- BLKW 1 ; Unused 
I.RWVB .BLKW 1 ; Virtual block number 
» BLKW 1 ; Unused 
1 ; 


I.LCKB: .BLKW Address of lock block 
The above fields are set up by routines in the Executive. 


Only I.LCKB is referenced by $IOFIN; it must be either 0 or 
greater than 140000. 
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L.EFN, i.PRI | pra 


FCN Function code | Modifier | 
Virtual address of I/O status block 
_ Relocation bias of I/O status block 


LIOSB 


Real address of 1/O status black 


Virtual address of AST service routine 


Device 
parameters 


|.AST 
|.PRM 


2K-228-81 


Figure D-2 I/O Packet 


D.5.2 The DCB 


The DCB is described 
following additional 


D.MSK 


In general, I/0 
the ACP; all 
calls S$GTPKT. 


D.5.3 The UCB 


The UCB is described 
following additional 


U.CTL 


in detail in Section 4.1.2 of this manual. The 
information applies to ACPs: 
requests marked as ACP functions are passed to 


others are passed to the device driver when it 


in detail in Section 4.1.4 of this manual. The 
information applies to ACPs: 
UC.QUE - Queue bypass bit 
If UC. QUE is set, all I/O requests are passed to the 


driver 


ACP-related processing in DROQIO. 
of 
system, 


use 


without being queued first, regardless of any 
A driver that makes 
option may alter the behavior of the file 


some functions are normally passed 


this 
since 


Girectiy to the ACP, bypassing the driver queue. 


U.STS 


U.CWl 


uc.KIL - 


US ..MNT 


US.FOR 


US.MDM 
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If UC.QUE and US.FOR are set, all DIGITAL-specific ACP 
processing is bypassed. In this case, the driver must 
do all address checking and relocation. 


The UC.QUE option allows user-written ACPs to validate 
the ACP function parameters. Each I/O driver supported 
by the user-written ACP must contain code to do _ the 
validation. The validation must be done at this point 
in the I/O processing, because the routines that do 
address checking and relocation assume that the memory 
Management registers are in use by the tasks issuing the 
I/o. (Refer to the DRQIO module for examples of the 
techniques used to validate and save parameters.) 


Unconditional cancel I/O call bit 


If UC.KIL is set, the I/O driver is called on a cancel 
I/O request even if the unit specified is not busy. 


Since ACP functions are dependent on sequencing, this 
function is normally turned into a no-op. 


An IO.KIL request has no effect on a mounted unit’ since 
the I/O queue is not flushed on the IO.KIL request when 
the DV.MNT (mountable) and US.MNT (mounted) bits are set 
for the unit. 


If US.MNT is set, the unit is not mounted. US.MNT is 
cleared when the volume is mounted. 


If US.FOR is set, the volume is mounted as_ foreign. 
US.FOR is set when the volume is mounted. 


If US.MDM is set, the volume is marked for dismount. 


An ACP normally checks the US.MDM bit when it processes 
a new I/O request. The ACP refuses operations that 
create a channel for processing (such as OPEN) when 
US.MDM is” set. After operations that terminate a 
channel (such as CLOSE), the ACP checks the current 
count of active channels to see if all ACP-related 
processing has been completed. If it is, the ACP 
completes the dismount. 


US.MDM is set when the volume is to be dismounted. 


This characteristics word is returned to the user task by the 
GLUN$ directive. U.CW1l is checked during validation of I/0 


request. 


DV. MNT 


The following bits are important to ACPs: 


If DV.MNT is set, the device is mountable. If a device 
is mountable, ACP functions can only be performed when 
it is mounted. 
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DV.F11 
If DV.Fll is set, the device is a Files-1l device. 
DV.F1ll is set for both disks and tapes. If the device 
is Files-1l1l, the DV.SQD bit determines whether’ the 
device is random or sequential. 

DV. COM 
If DV.COM is set, the device is mountable as a 
communications channel. This is used for DECnet. 

DV. SOD 
If DV.SOD is set, the device is sequential. If DV.SOD 
is reset, the device is random access. 

DV. SDI 
If DV.SDI is set, the device supports only a_ single 
directory. 

DV.DIR 


If DV.DIR is set, the device is a directory device. 


D.6 AN EXAMPLE OF AN ACP-I/O DRIVER COMBINATION 

The following is an example of an ACP, including a special driver used 
by the ACP. This ACP, supplied for demonstration purposes only, 
sounts the number of QOIOs to a terminal. 


The modules supplied and their respective functions are: 


QD PRE.MAC Prefix file for assembly 

QDDAT.MAC - Driver database 

ODDRV.MAC - Driver for ACP 

QDACP.MAC The ACP itself 

QDC ON, MAC The task for enabling and disabling the ACP 


Example D-1l An ACP-I/O Driver Combination 
-TITLE QDPRE 
-IDENT /O1/ 
~ENABL LC 
This structure is purely for purposes of example. It is not intended 


be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


Me Me Me Ne Ne 


to 
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**—QDPRE-QD: driver prefix file 


EXECUTIVE DEPENDENCIES 


The following is a list of the recognized Executive dependencies for the 
the OD: driver. If the implementation or functionality of the following 
features change, this driver and ACP may not function properly. 


1, The Executive I/O processing as described in RSX-11M Guide to Writing an 1/0 
Driver remains unchanged. 


2. The following Executive routines remain unchanged: 
SSWSTK (SWSTKS) 
SBLXIO 
SEXROQP 
X11 of the routines documented in the RSX-11M Guide to Writing an I/O Driver 


we Ne ne Ne Se Se Se [se Se ne Se ne ne ne Se se se ne se 


System Macro Calls 


me te te 


»MCALL UCBDFS$ 
UCBDFS$ 


QD driver-specific offsets 


me Ne Ne 


~ASECT 
~ =U. VCB+2 ; End of UCB 


U.QACP::.BLRW 
U.QCTL::.BLKW 
U.QLUN: :. BLKW 
U.QOTRN::.BLKW 


Address of QD ACP TCB 

ACP control and status word 

LUN used by ACP when doing I/0 for this unit 
Count of transactions outstanding to ACP 


Hee 
me Ne Ne Ne 


UQ.STP==100000 
UQ. ONL==40000 


Stop requested for ACP on this unit 
This unit onlne 


-PSECT 


Q$$D11=3 ; Number of units 
LDSQD=0 Driver loadable 


me 


.TITLE QDDAT 
IDENT /O1/ 


»ENABL LC 
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This structure is purely for purposes of example. It is not intended to 
be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


uA Ne Se me we 


**-QDDAT-OD: driver device tables 


The following data structure is designed with two things in mind: 
1. Providing the minimum structures to look like a disk 
2. Providing the minimum structures to satisfy the Executive 
and the MCR LOA commands. 


mo Ne Ne Ne Ne te tO Me Me 


SQDDAT:: > Start of ODDRV device tables 


. 


Link to next DCB ; 

Pointer to first UCB 

Device name 

Lowest and highest unit number ! 

Length of UCB 

Pointer to driver dispatch table, set by LOA 


QDDCB: .WORD 0 
.~WORD -OD0 
.ASCII /QD/ 
~BYTE 0,Q$$D11-1 
-WORD OQODND-QDST 
.WORD 0 


we 


se me Se Ne TO 


The following table defines the initial processing of I/O functions in the 
Executive QI1O directive processing. The legal functions selected are those 
of the standard disk drivers. 


Ne Me we se we 


»WORD 177037 
- WORD 000030 
-WORD 000000 
~WORD 177000 
-WORD 000777 
-WORD 000000 
-WORD 000000 
-WORD 000777 


Legal functions 0.-15. 
Control functions 0.-15. 
No-op functions 0.-15. 
ACP functions 0.-15. 
Legal functions 16.-31. 
Control functions 16.-31. 
No-op functions 16.-31. 
ACP functions 16.-31. 


me me Se Ne Ne te Se Ne Ne 


»WORD 0 PCB address of driver partition 
$$$=0 

eNLIST MD 

~ LIST ME 

-REPT QS$D11 

.IRP XX,\<$$$> 
QDST=. 3 Start of UCB 


-IF DF MSSMUP 


-WORD 0 ; Login UIC, multi-user protection system 
«WORD 0 ; Owning terminal UCB address 
« ENDC 
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-QD'XX':,WORD QDDCB 
-WORD -QD'XX 
-BYTE UC. PWFIUC.ALG!3 


Back pointer to DCB 

Redirect pointer 

Control flags byte, call on powerfail 
to allow proper setting of on-line/off-line bit 
~BYTE US.MNT Status byte 

~ BYTE 0 Physical unit number, does not apply 
-BYTE 0 7 Second status word 

-WORD DV.MNT!IDV.F11!DV.SDI!IDV.DIR ; Characteristic word 1 
~WORD 0 Characteristic word 2, size of device 
-WORD 0 Characteristic word 3 

«WORD 512. Characteristic word 4, buffer size 
»WORD $QD0 Pointer to SCB 


ee te te Oe 


' 
? 
7 
~WORD 0 7 Attached task TCB address 
»~BLKW 2 ; User buffer pointer 
- BLKW 1 7 and byte count 
-WORD 0 ; Address of file system ACP TCB 
»~WORD 0 ; Address of VCB for file system 
«WORD Q ; U.QACP-QDACP TCB address 
«WORD 0 ; U.QCTL-QDACP Control word 
«WORD "XX'4+] ; U.QLUN-QDACP LUN for I/0 
QDND=. ; End of UCB 
» ENDR 
$$$=S$$+1 
« ENDR 
-NLIST ME 
LIST MD 
$QD0:: .WORD 0,.-2 ; Device I/O queue 
-BYTE 0,0 ; Device priority and vector 
»BYTE 0,0 ; Current and initial device timeout count 
~BYTE 0,0 ; Controller index and device status 
~WORD 0 ; CSR address 
»~WORD 0 ; Address of I/O packet 
«BLKW 5 3; Fork block 
SQDEND:: ; End of QDDRV device tables 
. END 


-TITLE QDDRV 
-IDENT /01/ 


»~ENABL LC 
This driver is purely for purposes of example. It is not intended to 


be a useful driver nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


me Ne te we we 


**k-QDDRV-QD: driver 


me Se Ne te 


me Ne we 


me Ne Me 


SODTBL: :.WORD QDINI 


me we Ne 
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MACRO LIBRARY CALLS 


DRIVER DISPATCH TABLE 


Initiator entry point 
Cancel I/O entry point 
Device timeout entry point 
Powerfail entry point 


-WORD QDCAN 
»-WORD QDOUT 
~WORD QD PWF 


me me te Ne 


LOCAL DATA 


IF DF AUTOST 


ACPTNM: .RAD50 /QDACP / ; Default ACP task name 


we NO Se Me Ne Me Me te Me te Ne Ne Ne Se Ne Ne Se Me we Se Ne Se 


- ENDC 


**-QDINI - "Disk" Driver 


This driver, in conjunction with its Ancillary Control Processor (ACP) 
appears to be a disk, but its operational characteristics are 

unusual. The actual storage medium may be any of a number of devices 
including memory, disk, or DECnet link. No driver queue is maintained; 
all I/O packets are queued directly to the ACP. The cancel I/0, device 
timeout, and powerfail entry points are all-set to be no-ops. The actual 
processing of the request is left to the ACP. 


Remember, this driver is an example and demonstrates multiple features 
of the driver/ACP/Executive interface. 


Inputs: 
R5=UCB address 


The buffer address and count for IO.RLB and IO.WLB have been validated 

by DRQIO processing code. I0O.KIL, IO.ATT, and IO.DET are processed by 

the Executive's standard I/O processing routines. I0.CTL is queued directly 
to QDACP, 


-ENABL LSB 


QDINI: ; Driver initiation entry point 
CALL SGT PKT 3; Get I/O packet 
BCS EXIT 7 If CS none to get 
CLRB S.STS (R4) ; Unbusy controller since ACP does all work 
MOV R1,R3 3 Copy I/O packet address 
BIT #UQ.ONL,U.QCTL(R5) ; Unit online? 
BEQ 20$ ; If EQ no 
MOVB I. FCN+1(R3),RO ; Get function code 
CMPB #I0.RLB/400,RO ; Read logical block? 
BEQ QPRLB ; If EQ yes 
CMPB #IO.WLB/400,RO ; Write logical block? 
BNE ERRIFC 3; If NE no 


me Ne Ne Ne te Ne 


QPWLB: MOV 
BIT 
BNE 


QPRLB: CALL 
MOV 


MOV 


BNE 


108: INC 


ERRIFC: MOV 


IOFIN: CLR 
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#1E.WLK&377,R0 


, 


#DV. SWL,U.CW1(R5) 


IOFIN 


SB LKCK 
R3,Rl 


U.QOACP (R5),RO 


10$ 


AUTOST 


#ACPTNM, R3 
SSRSTD 
20$ 


#T3.ACP,T.ST3 (RO 


20S 
RO, U. QACP (R5) 


U. QTRN(R5) 
SEXRQP 


#IE.OFL&377,R0 
IOFIN 


#IE. IFC&377,R0 
Rl 
SIOFIN 


LSB 


me we Ne Ne Ne Se ~e Ne Ne Ne Ne Ne Ne = we ws 


=e 


me we Ne Ne Ne te 


we Ne we Me 


me NO Ne 


nee 


~e Ne 


Function specific validation routines. The checks here could 

be made later in the ACP, but they are easily made here and have 
the added benefit of saving of two context switches (to and from 
the ACP) to return an error. 


Assume write locked 

; Unit software write locked? 
If NE yes 

Join common code 


Check for valid logical blocks 
Restore the I/O packet address to Rl 


Get address of ACP's TCB. The offset U.ACP 
can NOT be used since file system ACP uses 
that location. The UCB is used for TCB 
because it is easy for the ACP to access 
(as opposed to some location within the 
driver). 


If NE the ACP has been started. 


The next few lines of code may be used as 
an alternate method of starting the ACP. 
They allow the ACP to be started 
automatically if it is installed. 

They can't be used in this application 
since ACP needs some initialization info 


If defined, auto start ACP 


Get address of ACP task name 
See if our ACP is installed 
If CS no 

: Built as an ACP? 

If EQ no 

Save address of ACP 


Increment count of transactions in ACP queue 
Queue to the ACP by priority and activate 
it. This request will unstop the ACP if 

is stopped or run it if its not active. 


Reference label 
T/O status of device not ready 
Finish I/O request 


I/O status of illegal function code 
Finish I/O request 


Second I/O status word 
Finish I/O request 
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**-QDPWF-Powerfail, Mark offline units offline 


we me Me 


QDPWF: BIT #UQ.ONL, OCTL(R5) ; Unit offline? 
BNE 10$ 3; If NE no 
BISB #US.OFL,U.Si2(R5) ; Set offline 
10S: ; Reference label 


**-QDCAN-Cancel I/O in progress, ignored 
**-QDOUT-Device timeout, does not apply 


me Ne Se Be 


ODCAN: 

QDOUT: 

EXIT: RETURN 
- END 
-TITLE QDACP 
~IDENT /01/ 
-ENABL LC 


me me Se Ne Me 


**-QDACP-OQD: driver ACP 


Me Me Se Ne 


MACRO LIBRARY CALLS 


we Ne Ne 


»~MCALL 
? 
; LOCAL DATA 
-Q10:: QIos 


~IOST:: .~BLKW 
- LOPKT::.BLKW 
~ACTUN: : .WORD 0 


ae Sed 


WTSE: WTSES 1 
IOSB: .- BLKW 2 
FID: » BLEW 3 


‘ 


This ACP is purely for purposes of example. 
be a useful ACP nor is it supported in any way. 
functional, complete, and representative of a valid interface. 


se ~e me se Me 


me 


These functions are no-ops 


It is not intended to 
It is, however, 


ALUNS$S, DIRS, Q1O$,WTSES$,WSIGSS 


pl,l,,IOSBy,+<sere7> + My own QIO DPB 


I/O status to return to user 
Address of current I/O packet 
Count of active units 

Wait for I/O completion 

I/O status block for my I/O 


File ID of work file 
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**-,START-ACP starting entry point 


=e Ne te 


~START: :CALL -INIT 3; Do one-time initialization 


**-.GTPKT-Get the next I/O packet from ACP queue and dispatch function 


me te me 


.GTPKT::CLR . TOPKT ; No I/O packet yet 
SWSTKS 30S t; Switch to system state to synchronize with 
77 Executive. This prevents context switching 
j7 and makes Executive routines accessable. 
37 On return from system state, execution will 
77 resume at 30$. This call also saves all 
77 registers. 
MOV STKTCB,RO 3; Address of my TCB (must be my TCB since 
3¢ can't execute in context of any other task 
ADD #T.RCVL, RO 77 Point to receive queue listhead 
CALL SQRMVF 37 Attempt to dequeue I/O packet from queue 
BCC 20S 77 If CC I/O packet removed from queue 
TST . ACTUN 37 Is this ACP still active for any units? 
BNE 10$ 37 If NE yes 
MOV STKTCB,R5 7; RS must be our TCB address 
JMP SDREXT tz No I/O requests in our queue and no active 
77 units, perform a task exit without any 
37 possibility of a race between QDCON 
3: inserting an I/O request in our queue 
77 and our task exit. 
108: JMP SSTPCT 37 Stop current task (us) and return to task 
+7 State. Once back in task state the PC will 
77 be at 30$, since once we are unstopped we will 
33 resume execution at 30$, not the next line. 
208: MOV R1,.IOPKT 77 Save I/O packet address. (Return to task 
77 State restores all registers.) 
RETURN 7? Return to task state. Complementary to 
+; SWSTKS. 
308: MOV - IOPRT, R3 } Get I/O packet address 
BEQ .»GTPRT ; If EQ none found in queue, try again since 
7 Someone unstopped us. 
MOV I.UCB(R3),R5 ; Get UCB address for request 


Process I/O request 


Do any initialization required 


me me we we we 


MOV #1S.SUC,.10ST ; Initial status of success 
CLR . [OST+2 J eee 
MOV #.QIO0+Q.IOPL,RO ; Point to parameter list are of our QIO DPB 
MOV #6,R1 : ; Number of words to clear 
40S: CLR (RO)+ 3; Clear them 
DEC Rl ; Done? 
BNE 40$ ; If NE no 
MOV U.QOLUN(R5),.QIO+Q.IOLU ; Setup LUN in DPB 


me te Me te Ne Ne Ne te SO NO 


100S: 


1108: 


me te Ne 


IEIFC: 


we Se Se Se Ne Ne te 


- IOFIN: 


108: 


20S: 


308: 
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Dispatch function 


R5=UCB Address 
R3=1/0 Packet 


MOVB 
CMPB 
BNE 
JMP 
CMPB 
BNE 
JMP 
CMPB 
BEQ 


MOV 


INPUTS: 


I. FCN+1 (R3) ,RO 
#10. RLB/400, RO 
100$ 

FCRLB 
#10.WLB/400, RO 
1108 

FCWLB 
#10.CTL/400,RO 
FCCTL 


Tllegal function code 


#IE.IFC&377,-I0ST ; 


I/O function is dispatched with the following registers 


And .QIO has the correct LUN plugged into the DPB 


Get I/O function code 
Read logical block? 
If NE no 

Process read 

Write logical block? 
If NE no 

Process write 

ACP control function? 
If EQ yes 


me TH Ne Me MO ty MO te fe 


I/O status of illegal function code 


**—, TOFIN-Finish I/O request returning status to user. 


.IOST=I/O0 status of current request 
. IOPKT=Address of I/O packet 


MOV 
MOV 
MOV 
MOV 
SWSTKS 
CLR 
DEC 


BNE 
BIT 


BEQ 
BITB 
BEQ 
TST 
BNE 
BIC 


BISB 
CLR 
INC 
JMP 


ASR 
BCC 
CALL 
DEC 
JMP 


. IOST, RO 
.I0ST+2,R1 
.IOPKT, R3 
I.UCB(R3),R5 
20$ 

. 1OPKT 

U. QTRN(RS5) 


10$ 


#U0.STP,U.QCTL(R 


10$ 


#US.MNT,U.STS(R5 


10$ 
U.ATT (R5) 
10$ 


#UQ.STP!UQ.ONL,U.QCTL(R5) ; 


Get 
Get address of I/O packet 
Get UCB address 
Switch to system state 
No I/O packet anymore 
Decrement count of outstanding I/O queued 
to ACP 
If NE more requests in queue 
3; Has a request to stop processing on 
this unit been received? 
If EQ no 
37 Unit still mounted? 
; If EQ yes 
Unit attached? 
If NE yes 


I/O status 


ee, RT i i i ae 
Me Ne Ne Ne te ee 


we 


- 
=e 


Clear our on-line bit and stop 
337 request flag 


#US.OFL,U.ST2(R5) ;; Mark unit offline 


U. QACP (R5) 
. IOPKT 
SIOFIN 


. L[OPKT 
30$ 

~CLOSE 
- ACTUN 
~GTPKT 


37 No ACP active on unit 
3; Flag to indicate unit went to off-line state 
3; Finish I/O request and return to task state 


Unit go to offline state? 

If CC no 

Close up shop on this unit 
Decrement count of active units 
Get next I/O request 


me Se Ne NO te 


me Ne Ne Se Se Ne Ne te Se Se Se Me Se Ne Ne Ne Se Ne Ne we we we te 


-DOIO: SWSTKS 108 


me Me te Ne te 


wo Ne me we 


me Ne Ne Ne 


30S: RETURN 
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**-,DOIO-Do I/0 for user to real device 


This routine maps to the users buffer(s) and issues an I/0 request that 

will use the requesting task's buffers. This occurs because the QIO 

processing uses the logical mapping, not the virtual mapping, to determine 

where buffers are located. By logical mapping, I mean the physical mapping 
contained in the memory management registers. Because we are privileged, 

no validity checking is made on the buffers, so it is possible to do I/0 

to buffers larger than the windows through which they are mapped, that is, greater 
than about 4KB. This routine will function properly if the ACP overmaps 

the I/O page because it switches to the system stack, hence to kernel mode. 
Therefore, this routine must not be mapped by APR 7. 


INPUTS: 
RO=Buffer 1 mapping for user APR 1 
Rl=Buffer 2 mapping for user APR 2 


OUTPUTS: 
I/O issued and completed 
If CC then IOSB is I/O status 
If CS then S$DSW is directive error 


Switch to system state 


MOV UISARO+2,2(SP) ; Save user APR 1 value in saved RO 
MOV UISARO+4,4(SP) ; And user APR 2 value in saved Rl 
MOV RO, UISARO+2 7 Map to user's first buffer 

MOV R1, UISARO+4 ; Map to user's second buffer 

INCB SCXDBL 7 Disable context switching 

RETURN ; Return to task state 


Reference label 


Issue the QIO directive, context switching is disabled so we don't have 
to worry about user APRs 1 and 2 being modified. However, we can't wait 
for the I/O to complete at this point. 


DIRS #.Q10 ; Issue I/O request 
ROR -(SP) ; Save carry state 


Buffers have been "validated" and relocated so we can restore original 
mapping and enable context switching. 


SWSTKS 205 Switch to system state 


‘ 
MOV RO, UISARO+2 3} Restore user APR 1 
MOV R1,UISARO+4 ; Restore user APR 2 
DECB SCXDBL 7 Enable context switching 
RETURN ; Return to user state 
‘ 


Reference label 


Context switching is now enabled, check directive status and if successful 
wait for completion 


ROL (SP)+ 
BCS 30$ 
DIRS #WTSE 


Restore carry, was directive successful? 
If CS no 

Wait for I/O to complete 

Return to caller 


me Ne te te 


me He Ne Ne Ne MO NO Me MO Me Ne tO 


~BLXTI: 


me Se Me Ne Ne Me Ne Ne MO Te Me te 


-BLXO: 
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INPUTS: 


RO=Byte count to transfer 
Rl=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 


OUTPUTS: 


Data in our buffer 
~ENABL LSB 


SWSTKS 20S 


i 
MOV RO,R5 : 
MOV R1l,-(SP) ; 
MOV R2,-(SP) ; 
MOV R3,RO0 ; 
CALL SRELOC ; 
MOV R1,R3 ; 
MOV R2,R4 ; 
MOV (SP)+,R2 : 
MOV (SP)+,R1l ; 
BR 10$ ; 


INPUTS: 


RO=Byte count to transfer 
Rl=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 


OUTPUTS: 


Data in user buffer 


SWSTKS 20S H 
MOV RO,R5 : 
MOV R3,R0 ; 
MOV R1,R3 ; 
MOV R2,R4 ; 
CALL SRELOC : 
MOV R5,R0 ; 
ADD #120000-140000,R2 
JMP SBLXIO ; 
RETURN ; 


-DSABL LSB 


**x-,BLXI-Transfer data into our buffer 


Switch to system State 

Save R5 

Save Rl 

And R2 

Set virtual address of our buffer 
Convert to address double word 
Copy Rl and 

R2 to proper place for $BLXIO 
Restore R2 

and R1 

Join common code 


**k—~,. BLXO-Transfer out of our buffer into user's buffer 


Switch to system state 

Save RO 

Set RO to address of our buffer for SRELOC 
Copy Rl and 

R2 into proper place for $BLXIO 

Convert to address doubleword 

Restore byte count 

; Convert to APR 5 displacement 

Transfer data and return to task state 
Return to caller 


drivers UCB. 


me Ne Ne te we Me te tO 


FCCTL: MOV 
BIT 
BEQ 
CMPB 
BEQ 
CMPB 
BEQ 
BR 


7 Process start 


108: TST 
BNE 
CALL 
BCS 
INC 
MOV 
BIS 
BICB 
BR 

208: MOV 
BR 
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**k-FCCTL-ACP control functions 
Two control functions are supported, start-up and shut-down. 


We check the request for validity and then set up various fields in the 


I.TCB(R3),R0 ; Get TCB address of issuing task 
#T3.PRV,T.ST3(RO) ; Task privileged? 

IEIFC 3; If EQ no 

#1,1.FCN(R3) ; Startup request? 

10$ ; If EQ yes 

#2,1.FCN(R3) ; Stop request? 

30$ ; If EQ yes 

IEIFC 7 Illegal function 

request 


U. QACP (R5) Already got an ACP? 


20$ ; If NE yes 
. OPEN ; Open up shop for unit 
100$ 3} If CS failed to open channel to "device" 


- ACTUN ; Increment count of units active 
STKTCB,U.QACP(R5) ; Set ACP TCB address in UCB 
#UQ.ONL,U.QCTL(R5) ; Set unit online 
#US.OFL,U.ST2(R5) ; And for the operating system 


100$ 3; Join common code 
#IE.RSU&377,-IOST ; ACP already started for unit error 
100$ ; Join common code 


3; Process stop request 


308: CMP 
BNE 
BIT 
BNE 
CALL 
BITB 
BEQ 
TST 
BNE 
CMP 
BNE 
BISB 
BIS 
RETURN 

408: MOV 
RETURN 


50S: MOV 
BR 


60S: MOV 


1008S: JMP 


STKTCB,U.QACP(R5) ; Unit online with correct ACP? 


50S ; If NE no 

#UQ.STP,U.QCTL(R5) ; Stop requested? 

60$ ; If NE yes 

SSWSTK, 1008S :; Go to system state to prevent a race problem 
#US.MNT,U.STS(R5) ;; Unit still mounted? 

40$ 33 If EQ yes 

U. ATT (R5) 7; Unit attached? 

40$ 3; If NE yes 

#1,U.QTRN(R5) 7; Is this this the only transaction queued? 
40s 73 If NE no 


#US.OFL,U.ST2(R5) ;; Mark unit off line to prevent further I/0 
#UQ.STP,U.QCTL(R5) ;; Request unit be stopped 

3; Return to task state at statement 100$ 
#IE.NFW&377,-I1O0ST 3; Unit busy, attached, or mounted 

;; Return to task state at statement 100$ 


#IE.OFL&377,.I0ST ; Unit offline 
100$ ;} Join common code 


#IE.FLN&377,.IO0ST ; Already being stopped; error 


. IOFIN ; Finish I/O request 


me 0 8 Me 8 Se Ne Ne Me we 


me we Ne 


FCRLB: 


me te Ne 


FCWLB: 


we te Ne 


208: 


3058: 
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W 


ARNING 


The above code must be in the first 8K of the ACP because 

a switch to system state uses the kernel mode mapping which 
allows only 8K for task mapping. (The I/O page is mapped in 
thru APR 7 in system state, but may be overlaid by the task 
in task state.) 


. ENABL 


CALL 
BCS 
MOV 
MOV 
MOV 
MOV 
MOV 
CALL 
BR 


CALL 
BCS 
MOV 
MOV 
MOV 
MOV 
CALL 
MOV 


LSB 


. READ 
10s 

I. PRM+4 (R3) ,RO 
RO, -IOST+2 

I. PRM(R3),R1 
I. PRM+2 (R3) ,R2 
R4,R3 

. BLXO 

30$ 


MO Ne te me Ne Me Ne NO Ne 


.WRITE 
10$ 

I. PRM+4 (R3),RO 
I.PRM(R3),R1 
I. PRM+2 (R3) ,R2 
R4,R3 

.BLXI 

. IOPKT, R3 


me me 8 Me Se Se M8 Me 


Do I/O from user buffer 


I.PRM(R3),RO 
I. PRM+2 (R3),R1 
#140000-20000,R1 
R1, .QT0+0. IOPL 


seose 


.DOIO 
20$ 
#1E.ABO&377,.10ST 
30$ 

IOSB,.I0ST 
IOSB+2,.I10ST+2 
. IOFIN 


mee Me we 


me te se Se 


LSB 


**-FCRLB-Read logical block function 


Data in memory already? 

If CS no 

Get byte count 

Set return status byte count 
APR mapping 

APR6 displacement 

Address of our buffer 
Transfer to user buffer 

Join common exit code 


**-PCWLB-Write logical block function 


Transfer data to our buffer first? 
If CS no 

Get byte count 

APR mapping 

APR6 displacement 

Address of our buffer 

Transfer to our buffer 

Restore I/O packet address 


Get mapping value for APR 1 

Get displacement biased for APR6 
; Adjust to an APR1 bias 

Insert virtual address of buffer when mapped 
‘via APR 1 

Issue I/O request 

If CC successful 

; Return error to user 

Join common code 

Return status to user 


Finish I/O request and dispatch next request 
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**—. INIT-One time initializations on startup 


-Se Me Me 


~ INIT: None 


=e te 


RETURN 


**—,OPEN-Open up I/O path for unit 


Inputs: 
R5=UCB address 
R3=I1/0 packet address 


me Se we Se NO we Ne 


.OPEN: ALUNSS U.OLUN(R5),#"SY,#0 ; Assign LUN to work file device 


BCS 208 ; If CS error 

MOV #I0.CRE,.QIO+Q.IOFN ; Setup for create file 

MOV #FID,.QIO+Q.IOPL ; Insert address to receive file ID 

MOV #100000, .QIO+Q0.I1OPL+4 ; Enable extend 

MOV I. PRM(R3),-QIO+0.IOPL+6 ; Allocate file of size requested 

CALL XIO ; Create and extend file 

MOVB IOSB,. 10ST ; Copy I/O status 

BMI 10$ ; If MI error 

CLR ~ O10+0. IOPL+4 ; Reset parameter 

CLR -Q10+0. IOPL+6 3; Ditto 

MOV #10. ACW,.QIO+Q.IOFN ; Set up to access the file 

MOV #100000,.Q10+Q.IOPL+10 ; Enable access 

CALL XIO ; Access file 

MOVB IOSB,.I10ST ; Copy I/O status 

BMI 10$ ; If MI error 

CLR ~QIO+Q.IOPL+10 ; Reset parameter 

MOV #IO.DEL, .QIO+O.IOFN ; Set up to mark file for delete 

CALL XIO : Mark file for delete 

MOV I.PRM(R3),U.CW3(R5) ; Set up device size 

RETURN : Successful exit with carry clear 
108: SEC : Error exit with carry set 

RETURN : 
208: CRASH ; Internal error 


7 
3 **-.CLOSE-Close channel to device 
7 


CLOSE: MOV #6,R0 ; Number of parameters to clear 
MOV #,Q10+0.IOPL,R1 ; Address of parameter list 
108: CLR (R1)+ : Reset parameters 
DEC RO : Done? 
BNE 10$ 3} If NE no 
MOV #10.DAC,.QIO+Q.1OFN ; Set to deaccess file 
JMP XIO ; Deaccess file 


*k—,READ-Determine method of performing read 


Inputs: 
R5=UCB Address 
R3=1/0 Packet 


me Ne we Me MO Me 


me Me A Me Ne Me MO 


~READ: 


108: 


me Me Me Ne te Ne Me Se te Me Ne Ne NO 


-WRITE: 


108: 


Outputs: 
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If CS then do I/O directly into user buffer 


-QIO0 DPB setup with I/O function code 


If CC then do I/O to our buffer, then copy to user buffer 


MOV 
MOV 
MOV 
MOV 
ADD 
ADC 
CMP 
BNE 
MOV 
MOV 
CALL 
TSTB 
BMI 
CLC 
RETURN 
SEC 
RETURN 


Inputs: 


R4=Address of buffer 


#I0.RVB,-QIO+Q.IOFN ; Set up to read 

I. PRM+4 (R3),-QIO+Q.IOPL+2 ; Insert byte count into DPB 

I. PRM+10(R3),-Q10+0.IOPL+6 ; And block number to start transfer 
I. PRM+12(R3),.QI0+Q.IOPL+10 ; 

#1,.QIO+Q.IOPL+10 ; Convert from “logical" to "virtual" 

. QT0+0. IOPL+6 


#1000,1I.PRM+4(R3) ; Do I/O to our buffer first? 

10$ If NE no 

#.BUF,R4 Set address of buffer 

R4,.QI10+0.IOPL Set up buffer address 

XIO Read data into our buffer 

IOSB On error go directly to user buffer; error? 
10$ If MI yes 


Copy to user buffer 


Do I/O directly to user buffer 


me me Se Se TO Ne Ne te TO Ne Ne NO 


**—,WRITE-Determine method of performing write 


R5=UCB Address 
R3=I1/0 Packet 


Outputs: 


Tf CS then do I/O directly from user buffer 


-Q1O DPB setup with I/O function code 


If CC then copy data to our buffer, then do I/O from user buffer 


R4=Address of buffer 


#IO.WVB,.QIO+Q.IOFN ; Set up to write 

I. PRM+4 (R3),-QI0+Q0.IOPL+2 ; Insert byte count into DPB 
I. PRM+10(R3),.Q10+0.IOPL+6 ; And block number on device 
I. PRM+12(R3),-QI0+Q.IOPL+10 ; 

#1,.QI1O0+Q.IOPL+10 ; Convert from “logical" to "virtual" 
. Q10+Q. IOPL+6 : 

#1000,1I1.PRM+4(R3) ; Copy to our buffer first? 

10s 3} If NE no 

#.BUF,R4 Address of buffer for data 

Copy from user buffer 


Do I/O directly from user buffer 


me Ne Se we MO 
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*%*-XTO-Execute QIO request 


me Me Ne 


XIO: DIRS #.QI0 7 Issue I/O request. 
BCC 10$ ; If CC successfully issued 
CMP #1IE.UPN, SDSW 7 No dynamic storage available? 
BNE 20$ 3; If NE no 
WSIGSS 3; Hope 
BR XIO 3; ».-hope 

108: DIRS #WTSE ; Wait for I/O to complete 
BCS 208 ; If CS error 
RETURN ? 

208: CRASH ; Internal error 

7 

7 I/O buffer 

’ 


BUF: - BLKB 1000 One block long 


=e 


- END - START 


.TITLE QDCON 
IDENT /01/ 


»~ENABL LC 
This control task is purely for purposes of example. It is not intended to 


be a useful task nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


me we Ne Ne Ne 


**-QDCON-QD: driver and ACP control task 


me Ne Ne we 


MACRO LIBRARY CALLS 


we Ne Ne 


-MCALL ALUNS,GLUNS,DIRS,GMCRS,WTSESS , QIOWSS, EXSTSS 
»-MCALL ISTATS,STATES, TRANS 


DEFINE PARSER STATE TABLE 
The following commands are supported: 


>QDC START QDn:/SIZE:n 
where 
START is the subcommand to startup the ACP specifying the "disk size" 


>QDC STOP QODn: 
where 
STOP is the subcommand to stop the ACP at the earliest opportunity 


Me me Ne Ne Me Ne Se Ne Se Me Ne Me te 


~~ 


=e 


= 


' 
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ISTATS QDCSTB,ODCKTB 
Skip command name 


STATES INITL 
TRANS SSTRNG 


Determine subcommand 
STATES 
TRANS "START" ,START, , SSTART, SDISPT 
TRANS "STOP", STOP, ,SSTOP, SDISPT 


Process START command, get device name 


STATES START 
TRANS {DEVICE 


STATES OPTION 
TRANS '/,SWITCH 
TRANS SEOS,SEXIT 


STATES SWITCH 


TRANS "SIZE",SIZE 
STATES SIZE 

TRANS t= 

STATES 


TRANS SNUMBR, OPTION, SETSIZ 
Process STOP command 


STATES STOP 
TRANS IDEVICE 


STATES 
TRANS $EOS, SEXIT 


Process device name 


STATES DEVICE 
TRANS SALPHA, , SETDV1 


STATES 
TRANS SALPHA, , SETDV2 


STATES 
TRANS SNUMBR, DEV1, SETUNT 
TRANS SLAMDA 


STATES DEVI 
TRANS '; ,SEXIT 


Terminate state table 


STATES 


=e te fe 


oy 


SETDVI1: 
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PARSER ACTION ROUTINES 


Set first character of device 


MOVB 
RETURN 


. PCHAR, SDEV 


name 


=e Ne 


Save first character of device name 


; Set second character of device name 


SETDV2: MOVB . PCHAR, SDEV+1 ; Save second character 
RETURN H 
: Set device unit number 
SETUNT: MOV .« PNUMB, SUNIT : Save converted unit number 
RETURN ? 
3 Set device size 
SETSIZ: MOV . PNUMB, SSIZE : Save converted size 
RETURN 7 
7 
; LOCAL DATA 
? 
ALUN: ALUNS Lyg : Assign LUN to QDn: 
SDEV= ALUN+A. LUNA ; Address of device name 
SUNIT= ALUN+A.LUNU ; Address of device unit number 
GLUN: GLUNS 1,GLUBUF ; Get LUN information for QD: device 
GLUBUF: .BLKW 6 ; LUN information buffer 
SPDEV= GLUBUF+G.LUNA : Actual device name 
SPUNIT= GLUBUF+G. LUNU ; Actual device unit 
SCHAR= GLUBUF+G.LUCW : Device characteristics word 
GMCR: GMCRS ; Get MCR command line 
SSIZE: .WORD 0 ; Device size to create 
SDISPT: .WORD 0 : Address of service routine 
ACPNAM: .RAD50 /QDACP / ; Name of ACP 
PRMLST: .BLKW 8. ; Parameter list for I/O packet 
SIOST: ~BLKW 2 3; I/O status 
H 
; Error messages 
? 
«MACRO ERM ERN,STS,TEXT 
»PSECT SSERMG 
$S$l=. 
ASCII <15>*TEXT* 
$$$2=. 
-PSECT 
ERN: ~WORD sTs 
»WORD $$$1,$$$2-$$$1 
. ENDM 


- MACRO 


. ENDM 


-MACRO 


- ENDM 


»MACRO 


- ENDM 


ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 


mo Me Ne 
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ERRX ERN 
MOV #ERN, RO 
JMP SERRXT 


FTLX ERN 
MOV #ERN, RO 
JMP $SUCXT 


SUCX ERN 
MOV #ERN, RO 
JMP $SUCXT 


ERRCML, 14,<%QDC-F-GETCOMFAIL, Failed to get command line> 
ERRSYN, 24,<%QDC-F-SYNERR, Syntax error in command> 

ERRNOD, 34,<%QDC-F-NOQDDEV, Failed to assign LUN to QD:> 

ERRBDV, 44,<%QDC-F-BADDEVICE, Invalid device specified> 

ERRNOD, 54,<%QDC-F-NOPOOL, No dynamic memory for I/O request> 
ERRNAC, 64,<%QDC-F-NOACP, QDACP not installed in system> 

ERRREO, 74, <$QODC-F-REQFAIL, Failed to request QDACP> 

ERRUSE, 104,<$QDC-F-DEVINUSE, Specified unit already in use> 
ERRINT, 114,<%QDC-F-INTERNAL, Internal error> 

ERRFLN, 124,<%QDC-F-OFFLINREQ, Unit already requested to offline> 
ERRNOL, 134,<%QDC-—F-NOTONLINE, Unit not online> 

ERRNDS, 144,<$QDC-F-NODISSPAC, Failed to allocate disk space> 
ERRBSY, 154,<%$QDC-F-DEVICEBUSY, Device busy, mounted, or attached> 
ERRFTL,0,<-QDC-F-ONLFAIL, Failed to bring unit online> 

SUCCOM, 161, <ZODC-S-ONLINE, Specified unit brought online> 
REQOFF, 171,<%QDC-S-REQOFFLINE, Unit requested to offline> 


**-—,QDCON-QD device control program 


SQODCON: CLR SDISPT ; Reset service routine dispatch address 
CLR SUNIT 3} Clean out unit number 
DIRS #GMCR ; Get the command line 
BCC 10$ 3 If CC successful 


108: 


308: 


FTLX ERRCML 


CLR Rl ; Suppress blanks 

MOV #QDCKTB,R2 ; Get keyword table address 

MOV SDSW, R3 ; Get length of command line 

MOV #GMCR+G.MCRB,R4 ; Get address of command line 

MOV #INITL,RS ; Get address of initial parser state 
CALL . TPARS ; Parse command line 

BCC 20$ ; If CC good command line 


FTLX ERRSYN 


DIRS #ALUN 
BCC 30$ 
FTLX ERRNOD 


Assign LUN to QD: 
If CC good device 


me me 


DIRS #GLUN Get device information 


~e 


JMP @SDISPT Dispatch to START or STOP service 


=~ 


me te me 


SSTART: 


108: 


208: 


30S: 
40S: 


1008: 


1108: 


1208: 


1308: 


me Ne Ne 


SSTOP: 


10S: 


1005S: 


1108: 
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**-SSTART-Start up ACP and specify size 


CMP 
BEQ 
FTLX 


MOV 
MOV 
MOV 
MOV 


CALL 
BCC 
CMP 
BNE 
ERRX 
CMP 
BEQ 
CMP 
BNE 
ERRX 
ERRX 


CMPB 
BNE 
SUCX 


CMPB 
BNE 

ERRX 
CMPB 
BNE 

ERRX 
FTLX 


**-S$STOP-Stop 


CMP 
BEQ 
FTLX 


MOV 
MOV 
MOV 


CALL 
BCC 
CMP 
BNE 
FTLX 


CMPB 
BNE 
SUCX 


CMPB 
BNE 
FTLX 


#"0D,SPDEV 
10s 
ERRBDV 


S$SIZE, PRMLST 
#PRMLST, R4 
#ACPNAM, R3 
#I10.CTL!1,R2 


.QUEIO 

100$ 
#IE.UPN, SDSW 
20$ 

ERRNOD 

#IE. INS, SDSW 
308 

#IE. PRI, SDSW 
40$ 

ERRNAC 
ERRREQ 


#I1S.SUC,$IOST 
110$ 
SUCCOM 


#IE.RSU,SIOST 
120$ 

ERRUSE 
#IE.DFU,SIOST 
1308 

ERRNDS 

ERRINT 


ACP operation 


#"QD, SPDEV 
10$ 
ERRBDV 


#PRMLST, R4 
#AC PNAM, R3 
#I0.CTL!2,R2 


- QUETIO 

100$ 
#IE.UPN, SDSW 
140$ 

ERRNOD 


#IS.SUC,$IOST 
110$ 
REQOFF 


#IE.FLN,SIOST 
120$ 
ERRFLN 


meme M8 Ne me me MO Ne Me Me Ne Me we 


mse Me Ne 


PT, i i i ~~ 


me SO Ne 


Really QD:? 
If EQ yes 


Address of parameter 

Get address of parameter list 

Get address of ACP task name 

Set function code of ACP control 
and subfunction of START (1) 
Queue an I/O request to the ACP 
If CC successfully queued 

No pool? 

If NE no 


ACP not installed? 
If EQ yes 

Not an ACP? 

If NE no 


Catchall error message 


Success? 
If NE no 
Successful completion 


Already got an ACP or already started? 
If NE no 


Device full? 
If NE no 


Catchall error message 


Really QD:? 
If EQ yes 


Get address of parameter list 

Get address of ACP task name 

Set function code for ACP control 
and subfunction of STOP (2) 
Queue an I/O request to the ACP 
If CC successfully queued 

No pool? 

If NE no 


Success? 
I£ NE no 
Successful completion 


Already being off-lined? 
If NE no 
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1208S: CMPB #IE.NFW,SIOST ; Unit busy? 
BNE 1305 3; If NE no 
FTLX ERRBSY 

130S: CMPB #IE.OFL,$SIOST Device not on line? 
BEQ 140$ If EQ yes 


FTLX ERRINT 
1408: FTLX ERRNOL 


Catchall error message 
Not on line 


a eT 


**-,QUEIO-Create and queue an I/O packet directly to an ACP 


This routine builds an I/0 packet and queues it directly to an 

ACP bypassing the Executive QIO directive processing. The primary 

reason for doing this is the fact that under some circumstances 

the ACP cannot be reached by going through the driver, such as when the 
ACP has not been started. The parameter list is copied into the I/0 packet 
without modification. Consequently, a buffer address cannot be passed 

as a parameter; it must first be relocated and the address double word 
placed in the parameter list; this routine is not designed to do that. 


INPUTS: 
R4=Parameter list address 
R3=Address of ACP task name 
R2=1/0 function code 
LUN 1 assigned to device associated with ACP 


OUTPUTS: 
If CC ACP requested and I/0 complete 
SIOST is I/O status block containing return from ACP 
If CS ACP not requested 
SDSW is error status 
IE.UPN - No dynamic memory for I/O packet 
IE.INS - ACP not installed 
IE.PRI - Task not an ACP 


If entry at .QUEIO, all registers preserved 


me me Ne Ne te Me 8 me Ne Ne Ne Ne Ne Ne Ne Ne Se Se Se Se He Me Ne 8 8 Be Se HO Ne 


-ENABL LSB 


-QUEIO: SWSTKS 40S Switch to system state 


or 

CLR SIOST 77 Clear I/O status block 

CLR SIOST+2 77 Indicating I/O pending 

MOV SHEADR,R5 77 Get address of our task header 

MOV H.LUN(R5),R5 33 Get device UCB address 

MOV #IE. INS, SDSW 37 Assume task not found 

CALL SSRSTD 3? Search for task 

BCS 30$ 37 If CS failure 

MOV #IE.PRI,SDSW 7? Assume task not an ACP 

BIT #T3.ACP,T.ST3 (RO) ;; Task an ACP? 

BEQ 30$ 77 If EQ no 

MOV RO,-(SP) 37 Save TCB address 

MOV R2,-(SP) 37 Save I/O function code 

MOV #IE.UPN, SDSW +7 Assume buffer allocation failure 

MOV #1.LGTH,R1 77 Length of I/0 packet 

CALL SALOCB 77 Allocate buffer from pool 

BcSs 308 33 If CS failure 

MOV (SP)+,R3 77 Restore R3 

MOV RO,-(SP) 37 Save address of I/O packet 

ASR Rl 77 Convert size in bytes to words 
108: CLR (RO)+ tz Zero I/O packet 

DEC Rl 37 Done? 

BNE 10$ i; If NE no 

MOV #STOST,RO 73 Get I/O status block address 


USER-WRITTEN 


CALL SRELOC 
MOV (SP)+,R0 
MOV #SIOST,1I.IOSB(RO 
MOV R1,1.IOSB+2 (RO) 
MOV R2,1I.I0SB+4 (RO) 
MOV STKTCB,1I.TCB(RO) 
MOVB #1,1.EFN(RO) 
MOVB #251.,1.PRI(RO) 
MOV R5,1.UCB(RO) 
MOV R3,1.FCN(RO) 
MOV RO,R1 
ADD #1. PRM, RO 
MOV #8.,R2 
208: MOV (R4)+, (RO)+ 
DEC R2 
BNE 20S 
MOV (SP)+,R0 
INC U. OTRN(R5) 
CALL SEXROP 
MOV STKTCB,RO 
INCB T, IOC (RO) 
CLR T. EFLG (RO) 
MOV #IS.SUC, SDSW 
308: RETURN 
40S: TST SDSW 
SEC 
BLE 50$ 
WTSESS #1 
508: RETURN 
-DSABL LSB 


**k-SERRXT-Error exit 
**-SSUCKT-Success exit 


‘ 

' 

i 

3 

; Inputs: 

; RO=Error table entry 

f 

; Outputs: 

7 Message and task exit 
~ENABL LSB 

SERRXT: MOV (RO)+,R5 ; Get 
MOV (RO)+,R1 ; 
MOV (RO)+,R2 ; 
QIOWSS #IO.WVB,#5,#5,,77,<R1,R2, 
Bcc 10$ 
IOT 

108: MOV #ERRFTL+2,R0 7 
BR 20S ; 

SSUCXT: MOV (RO)+,R5 H 

208: MOV (RO)+,R1 ; 
MOV (RO)+,R2 : 
QIOWSS #I0O.WVB,#5,#5,,,,<R1,R2, 
BCC 30$ 
IoT 

30S: EXSTSS R5 : 
~DSABL LSB 
. END SQDCON 


me eee te te we THE Ne Ne we FO TO MO Ne Se Ne NH Ne NH NO NES 
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Relocate it 
Restore packet address 
33 Insert virtual address of status block 
Insert relocation bias and 
Offset of I/O status block 
; Insert our TCB 
Insert event fiag number 
Insert priority 
Insert device UCB 
Insert function code 
Copy address of packet 
Point to parameter area 
Set parameter count 
Copy parameter list into packet 
Done? 
If NE no 
Get ACP TCB address 
Bump count of transactions queued to unit 
Queue I/O packet to ACP by priority and 
ensure ACP is active 
Get our TCB address 
Bump our I/O count 
Clear event flag 1 
Indicate success 
Return to task state 
QIO successful? 
Assume error 
If LE no 
Wait for I/O to finish 
Return to caller 


exit status 
Get address of error text 
Get size of text 
40> Write message 


, 


Get address of fatal error message 
Join common code 

Get exit status 

Get address of final message 

Get size of message 

40> Write message 


v 


Exit with status 


D-32 


SACHCK routine, 5-2 
SACHKB routine, 5-2 
ACP, 
See Ancillary Control 
Processor 
ACP I/O function mask, 4-12 
Address doubleword, A-1l 
SALOCB routine, 5-3 
Alternate CLI support, 
UCB field, 4-25 
Ancillary Control Processor 
(ACP), D-1 
as extension of Executive, 
D-5 
as task, D-4 
attributes, D-4 
enabling and disabling 
capacity, D-5 
example, D-1l 
for class of devices, D-4 
I/O request flow, D-5 
processing, D-6 
role of, in I/O processing, 
2-3 
shareability, D-5 
type, D-2 to D-3 
SASUMR routine, 5-4, B-3 


Buffer, 
special, 6-9 


Cancel I/O entry point, 2-4 
DDT conditions, 4-10 
CDA, 
See Crash Dump Analyzer 
CINTS directive, 3-1 
CLI Parser Block (CPB), 
address in UCB, 4-25 
SCLINS routine, 5-5 
Conditional assembly symbol, 
LDSxx, 3-5 
Conditional routine, 5-1 
Control and status register 
(CSR), 
address in SCB, 4-22 
Control I/O function mask, 
4-12 
Controller number, 2-14 
CPB, 
See CLI Parser Block 
Crash Dump Analyzer (CDA), 
debugging driver code, 3-20 
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SCRAVL symbol, 
use of, in fault tracing, 


3-28 
CSR, 
See Control and status 
register 


Data base, driver, 
accessing shared, 2-9 
changing, 3-3 
controlling access to 

shared, 2-10 

example, 6-2 to 6-4 

loadable, 

See Loadable data base 

overview, 3-5 

resident, 

See Resident data base 

Data structure, 2-7 
See also System data 

structure macro 
definition 

ACP interface, D-7 

DH11 terminal multiplexer, 

2-7 

figure, 2-19 

interaction with driver, 2-5 

interrelationship, 2-18 

macro definition, 

overview, 4-1 

RL11 disk, 2-8 

summary, 2-20 
DSSBUG label, 3-19 
DCB, 

See Device Control Block 
DDT, 

See Driver Dispatch Table 
SDEACB routine, 5-6 
Debugging, 

CDA, 3-20 

Executive stack and register 

dump routine, 3-16 

fault code, 3-26 

fault isolation, 

3-20 to 3-23 

fault tracing, 3-23 to 3-28 

Panic Dump routine, 

3=19-to.3-290 

XDT, 3-15, 3-17 to 3-18 
Debugging aid, 3-16 
SDEUMR routine, 5-7, B-3 
SDEVHD word, 2-19 

role of, in I/O data 

structure, 2-20 
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Device Control Block (DCB), 
description, 4-7 
relationship of, with I/0 

control blocks, 2-6 
required field, 3-6 
role of, in I/O data 

structure, 2-20 
with ACP, D-9 

Device Control Block (DCB) 

field, 
D.DSP, 3-6, 4 
D.LNK, 3-6, 3 
D.MSK, 3-6, 4- 
D.NAM, 3-6, 4 
D.PCB, 3-6, 4 
D.UCB, 3-6, 3 
D.UCBL, 3-6, 4- 
D.UNIT, 3-6, 4-9 

Device interrupt entry point, 

2-4 

Device interrupt vector, 4-33 
definition, 2-10 

Device time-out entry point, 

2-4 
DDT conditions, 4-11 
Directive Parameter Block 
(DPB), 2-5 
description, 4-6 
source of I/O packet 

information, 2-9 

DPB, 


See Directive Parameter Block 


Driver, 
changing code, 
debugging, 
See Debugging 
function, 1-2 
loadable, 
See Loadable driver 
multicontroller, 2-10 
Non-MASSBUS NPR, B-1 
postinitiation service, 2-11 
preinitiation processing of, 
2-11 

process-—like characteristic, 
2-13 

property, 1-2 

rebuilding and 
reincorporating, after 
debugging, 3-29 to 3-30 

resident, 

See Resident driver 
role of, in RSX-11M, 2-5 
Software Performance Report 

(SPR) support, 3-4 
SYSGEN support, 3-l 
type, 1-1 


Driver code, 
changing, 3-3 
example, 6-4 to 6-9 
overview, 3-4 
Driver data base, 
See Data base, driver 
Driver Dispatch Table (DDT), 
address, 3-5 
role of, in I/O data 
structure, 2-20 
Driver entry point, 
cancel I/O, 2-4, 4-10 
device interrupt ;2-4 
device time-out, 2-4, 
4-11 
I/O initiator, 2-4, 2-12, 
4-10 
power failure, 2-4, 4-11 
Driver global symbol, 
SxxINP, 3-5 
$xxINT, 3-5 
$xxOUT, 3-5 
$xxTBL, 3-5 
DROIO module, 
service performed in 
processing QIO, 2-11 
SDVMSG routine, 5-8 


Error logging, 
modifying driver to 
incorporate, 3-5 
SCB field, 4-20 
UCB field, 4-24 to 4-25 
Executive Crash Dump routine, 
3-20 
Executive Debugging Tool 
(XDT), 
debugging driver code, 
3-17 to 3-18 
ODT features and commands 
not included, 3-17 
Executive service, 
driver processing, 2-10 
postinitiation, 2-11 
preinitiation, 2-11 
Executive service calls, 
5-1 to 5-28 
Executive stack and register 
dump routine, 3-17 
debugging driver code, 
3-16 
use of, in fault tracing, 
3-25 
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SEXROP routine, 5-9 
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FII1ACP, 
role of, in I/O data 
structure, 2-19 
Fault code, 3-26 
Fault isolation, 3-20 to 3-23 
Fault tracing, 3-23 to 3-24 
after unintended loop, 3-28 
Executive stack and register 
dump, 3-25 to 3-27 
hints, 3-28 to 3-29 
in new driver, 3-28 
when processor halts without 
display, 3-27 
FCP, 
See File Control Processor 
FCS, . 
See File Control Services 
File Control Block (FCB), 
role of, in I/O data 
structure, 2-20 
File Control Processor (FCP), 
role of, in I/O data 
structure, 2-19 
File Control Services (FCS), 
position of, in I/O 
hierarchy, 2-2 
Fork block, 
storage words in SCB, 4-23 
Fork level processing, 2-15 
Fork list, 2-9 
Fork process, 2-9 
creating with SFORK, 2-12 
SFORK routine, 5-10 
accessing shared driver data 
base, 2-10 
initiating fork process, 2-9 
SFORK1 routine, 5-11 
Function mask word, 
See I/O function mask 


Global label, 
SUSRTB, 3-13 
$xxDAT, 3-9 
SxxEND, 3-9 
SxxTBL, 4-10 
SGTBYT routine, 5-12 
SGTPKT routine, 2-12, 5-13 
in driver processing, 2-17 
use of, with ACP, D-6 
SGTWRD routine, 5-14 
conditional assembly, 5-1 
inclusion of, by SYSGEN, 3-2 
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SHEADR pointer (Cont.) 
3-24 


ICB, 
See Interrupt Control Block 
Interrupt Control Block (ICB), 
3-2, 4-35 
Interrupt entry point, 
address, 3-5 
Interrupt processing, 

fork level, 2-9, 2-15 

priority 7, 2-14 

priority of interrupting 
source, 2-14 

INTSV$ macro, 
description, 4-35 
format, 4-35 
SINTSV routine, 2-12, 5-15 
calling with INTSV$ macro, 
4-35 

processing at priority of 
interrupting source, 
2-15 

SINTXT routine, 5-16 

I/O control blocks, 
interrelationship, 2-6 

I/O data structure, 

See also System data 
structure macro 
definition 

See Data structure 

I/O driver, 
See Driver 
I/O function mask, 

ACP, 4-12 

control, 4-12 

creating, 4-13 

legal, 4-12 

no-op, 4-12 

values for disk drive, 4-16 

values for magtape drive, 
4-17 

values for standard 
functions, 4-15 

values for unit record 
device, 4-18 

I/O hierarchy, 2-1 
I/O initiator entry point, 
2-4, 2-12 
DDT conditions, 4-10 
I/O packet, 2-8 

description, 4-2 

format, 4-3 

pointer in SCB, 4-21 


I/O packet field (Cont.} 
I.EFN, 4-3 
I.FCN, 4-4 
I.IOSB, 4 
I.LNK, 
I.PRI, 
I.PRM, 
I.TCB, 
I.UCB, 4-4 
I/O philosophy, 2-1 
I/O processing, 
ACP, 2-3 
QIO directive, 
I/O queue, 2-9 
I/O request, 
flow, 2-16 to 
SIOALT routine, 
SIODON routine, 2-13, 
SIOFIN routine, 5-18 
use of, by ACP, D-7 


2-3 


2-17 
2-13, 5-17 


5-17 


LDSxx symbol, 3-5 
required by INTSVS macro, 
4-35 
Legal I/O function mask, 
LOA command, 4-35 
action if UC.PWF set, 2-4 
effect of, when loading 
driver, 3-8 
loading driver, 3-2, 
Loadable data base, 
advantage, 3-8 
assembling, 3-9 
characteristics, 
Loadable driver, 
assembling, 3-9 
benefit, 1-1 
combination with data base, 
3-1 
debugging, 3-8 
definition, 1-1 
incorporating, with data 


4-12 


3-12 


3-8 


base, 3-8 

linking, with loadable data 
base, 3-3 

linking, with resident data 
base, 3-3 

loading, into memory, 3-2, 
3-12 


rebuilding and 
reincorporating, after 
debugging, 3-30 
removing, from memory, 3-2 
task-building, 
Mapped system, 3-10 
unmapped system, 3-11 


INDEX 


Loadable driver (Cont.) 
task-building, with resident 
data base, 3-12 
Logical unit number (LUN), 
2-19 
preinitiation processing of, 
2-11 
Logical Unit Table (LUT), 
LUN, 
See Logical unit number 
LUT, 
See Logical Unit Table 


2-19 


Mapping register assignment 
block, 
allocating, B-2 
figure, B-3 
SMPUB1 routine, 5-20, B-3 
use of, to obtain UMRs, B-1l 
SMPUBM routine, 5-19, B-3 
use of, to obtain UMRs, B-1l 
Multicontroller driver, 2-10 
conditional code 
description, 4-33 
conditional code example, 
4-34 


No-op I/O function mask, 4-12 
NPR device driver, B-l 
use of SCB field S.MPR, 


NSSUMR symbol, B-4 


4-23 


Panic Dump routine, 3-19 
sample output, 3-20 
Partition Control Block (PCB), 
address in DCB, 4-14 
SPKAVL symbol, 
use of, in fault tracing, 
3-28 
Power failure entry point, 
DDT conditions, 4-11 
Process, 
state, 2-10 
Programming convention, 2-13 
Programming protocol, 2-14 
summary, 2-16 
SPTBYT routine, 5-21 
SPTWRD routine, 5-22 
conditional assembly, 5-1 
inclusion of, by SYSGEN, 3-2 
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SQINSP routine, 5-23 
QIO directive, 
position of, in I/0 
hierarchy, 2-2 
preinitiation processing of, 
2-11 
role of, in I/O processing, 
2-3 
QTO Directive Parameter Block, 
4-6 
SORMVF routine, 5-24 
use of, with ACP, D-6 


Record Management Services 
(RMS) , 
position of, in I/O 
hierarchy, 2-2 
RED command, 2-6 
SRELOC routine, 5-25 
Resident data base, 
assembling, 3-12 
example, 6-1 
Resident driver, 
assembling, 3-13 
combination with data base, 
3-1 
definition, 1-1 
example, 6-1 
incorporating, 3-13 
linking data base, 3-3 
rebuilding and 
reincorporating, after 
debugging, 3-29 
task-building, 3-14 


RMS, 
See Record Management 
Services 
SCB, 


See Status Control Block 
Special buffer handling, 6-9 
example, 6-9 to 6-11 
SST fault, 
abnormal, 3-27 
internal, 3-26 
Stack structure, 
abnormal SST fault, 3-27 
data items on stack, 3-28 
internal SST fault, 3-26 
Status Control Block (SCB}, 
description, 4-19 
relationship of, with I/0 
control blocks, 2-6 
required field, 3-7 
role of, in I/O data 
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Status Control Block (SCB) 
(Cont.) 
structure, 2-20 
Status Control Block (SCB) 
field, 
S.BMSK, 4-20 
S.BMSV, 4-20 
S.CON, 3-7, 4-22 
S.CSR, 3-7, 4-22 
S.CTM, 4-21 
S.FRK, 3-7, 4-23 
S.ITM, 3-7, 4-21 to 4-22 
S.LHD, 3-7 to 3-8, 4-2, 4-29 
S.MPR, 3-7, 4-23, B-l to B-2 
S.PKT, 4-23 
S.PRI, 3-7, 4-21 
S.RCNT, 4-20 
S.ROFF, 4-20 
S.STS, 3-7, 4-22 
S.VCT, 3-7, 4-21 
SSTKDP pointer, 
use of, in fault tracing, 
3-23 
SSTMAP routine, 5-26, 
B-2 to B-3 
use of, to obtain UMRs, B-1 
SSTMP1 routine, 5-27, 
B-2 to B-3 
use of, to obtain UMRs, B-1 
SSTPCT routine, 
use of, by ACP, D-7 
SSWSTK routine, 5-28 
Symbolic offsets, 
for system data structures, 
C-1 
SYSCM, 
See System common 
SYSTB file, 
creation of, by SYSGEN, 3-l 
System common (SYSCM), 
use of, in fault isolation, 
3-23 
System common (SYSCM) pointer, 
SCRAVL, 3-28 
SHEADR, 3-24, 3-27 
SPKAVL, 3-28 
SSTKDP, 3-23, 3-27 
STKTCB, 3-24, 3-27 
System data structure macro 
definition, C-l 
ABODFS, C-3 
CLKDFS, C-4 
DCBDFS, C-6 
EPKDFS, C-7 
F1IDFS, C-14 
HDRDFS, C-1l 
HWDDFS, C-21 
ITBDFS, C-24 
LCBDFS, C-25 
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System data structure macro 
(Cont.) 
MTADFS, C-26 
PCBDF$, C-30 
PKTDF$, C-32 
SCBDF$, C-37 
TCBDFS$, C-39 
UCBDFS$, C~42 
System generation, 
incorporating driver, 3-1 
System state register 
convention, 5-1 


Task header, 
mapped system, 3-25 
role of, in I/O data 
structure, 2-19 
unmapped system, 3-24 
STKTCB pointer, 
use of, in fault tracing, 
3-24 
Transfer function, 
processing, 4-13 
TTDRV, 
LOA special case, 3-5 


UCB, 
See Unit Control Block 
UNIBUS Mapping Register, 
Static allocation of, during 
system generation, B-4 
Unit Control Block (UCB), 
description, 4-23 
figure, 4-26 
negative offset, 4-9 
relationship of, with I/O 
control blocks, 2-6 
required field, 3-7 
role of, in I/O data 
structure, 2-20 
with ACP, D-9 
Unit Control Block (UCB) field, 
U.ATT, 3-7, 4-31 
U.BUF, 4-31 
U.CLI, 4-25 
U.CNT, 4-32, B-1 


U.CTL, 2-9, 3-7, 4-10, 4-27 
U.CW1l, 3-7, 4-29 
U.CW2, 3-7, 4-30 
U.CW3, 3-7, 4-30 
U.CW4, 3-7, 4-31 
U.DCB, 3-6 to 3-8, 4-9, 4-27 
U.ERHC, 4-25 
U.ERHL, 4-24 
U.ERSC, 4-24 
U.ERSL, 4-24 
U.IOC, 4-24 
U.LUIC, 4+25 
U.MUP, 4-25 
U.OWN, 4-27 
U.RED, 3-7 to 3-8, 4-27 
U.SCB, 3-7 to 3-8, 4-31 
U.ST2, 3-7, 4-29 
U.STS, 3-7, 4-28 
U.UNIT, 3-7, 4-29 
UNL command, 
unloading driver, 3-2 
USRTB file, 
content, 3-12 
SUSRTB label, 3-13 


Volume Control Block’ (VCB), 
role of, in I/O data 
structure, 2-20 


Window Block (WB), 
role of, in I/O data 
structure, 2-19 to 2-20 


XDT, 
See Executive Debugging Tool 
SxxDAT label, 3-9 
SxxEND label, 3-9 
$xxINP symbol, 3-5 
SxxINT symbol, 3-5 
$xxOUT symbol, 3-5 
$xxTBL label, 
on driver dispatch table 
(DDT), 4-10 
$xxTBL symbol, 3-5 
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